Removing OnlyShowIn / NotShowIn from desktop actions
Aaron J. Seigo
aseigo at kde.org
Wed Jul 3 08:43:44 PDT 2013
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
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the xdg