Removing OnlyShowIn / NotShowIn from desktop actions

Jasper St. Pierre jstpierre at
Wed Jul 3 09:33:59 PDT 2013

I think this is getting a bit excessive. We don't need to enumerate every
single place a desktop environment should put actions, we should simply
specify that they should appear around the launcher in the specification.
And if an action appears in both the messaging menu and the launcher menu,
oh well? The user will cope, I think.

On Wed, Jul 3, 2013 at 11:43 AM, Aaron J. Seigo <aseigo at> wrote:

> On Wednesday, July 3, 2013 10:15:45 Lars Uebernickel wrote:
> > On 07/02/2013 06:09 PM, Ted Gould wrote:
> > > The use case was two fold.  First there was concern that some desktops
> > > might not want to implement the actions or might implement them
> > > differently.  It's also possible that desktops could put different sets
> > > of actions in different places.  For instance, the Unity Launcher vs.
> > > the Messaging Menu.  This way some items could be in one, the other, or
> > > both depending on how the values are set.
> >
> > I agree that it seems like it might be useful for applications to show
> > actions only in specific parts of the UI. However, I can't find an
> > application that does this right now for the messaging menu.
> >
> > Also, this goes against the spec, because "MessagingMenu" is not a
> > registered value.
> honestly, this looks like something that should be in a different
> specification
> altogether.
> prior art in this direction:
> * the status notifiers / app indicators spec we solved this issue for
> categorizing entries for running applications.
> * mpris2 allowed the creation of things like the sound menu we see in
> various
> places
> these obviously have covered only running applications, but both work very
> very well given their focus (as opposed to re-use of a
> not-quite-appropriate
> area) and their clear separation of data and visualization.
> if we wish to see categorization of actions for applications that may not
> yet
> be running, a similar system that is focused on providing integration with,
> e.g. a presence or messasging menu, would make sense that is separate from
> the
> application .desktop structure.
> this would future proof those .desktop files from such features become
> passe
> and abandoned and would allow the creation of a system well designed for
> the
> use case of message population.
> an example of how this could matter: if every application implements a
> "Compose message" action on their own ... how does a shell present these
> in a
> consisten fashion? probably can't, since it is up to each application
> developer which means variance will occur.
> this is actually a good (bad? :) example of breaching the veil between
> application metadata and presentation in the target shell.
> instead, applications should be able to register themselves as "composers
> of
> messages of type [email|SMS|...]" and the shell should take care of
> presenting
> that to the user in a form factor and environment appropriate manner.
> therefore i don't think this kind of feature belongs in the application
> .desktop files at all. it leads to the kind of malformations we already
> see now
> as environments experiment with (currently) modern features such as a
> messaging menu and applications try to adapt while simultaneously making
> consistency next to impossible.
> > > It seems to me like they are using the values correctly, but have been
> > > set more specific than you'd prefer.  I'd imagine that most upstreams
> > > would be willing to accept patches to adjust the values if GNOME Shell
> > > is getting support for them.
> >
> > Definitely. I think we should just discourage their use in general, but
> that hardly ever works ime. application developers take advantage of
> anything
> that made available, whether a central authority deems it kosher or not.
> > keep them to enable some specific use-cases (for example "Open Window on
> > a New Workspace" wouldn't work on all desktops, and "Start Minimized"
> > makes no sense in GNOME shell).
> should those be actions provided in an application's .desktop file though?
> seems like something that the shell should be inserting itself, not
> something
> down on an application-by-application basis.
> --
> Aaron J. Seigo
> _______________________________________________
> xdg mailing list
> xdg at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the xdg mailing list