Removing OnlyShowIn / NotShowIn from desktop actions

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20130703/88a5de86/attachment-0001.pgp>