Removing OnlyShowIn / NotShowIn from desktop actions

Aaron J. Seigo aseigo at
Wed Jul 3 01:38:40 PDT 2013

On Tuesday, July 2, 2013 20:48:55 Ryan Lortie wrote:
> > or might implement them differently.
> This is a good point that I hadn't considered before.  Maybe gnome-shell
> would show them in a place that Transmission considered inappropriate.

Should the application care about this at all? I'd suggest "no" for the 
following reasons:

* desktop shells may adjust their behaviour, and expecting application 
developers to respond to the current behaviour of the shell makes it nearly 
impossible (multiple versions of the same shell with different behaviours, 
having to propagate changes out to each and every application, etc.)

* the application developer is unlikely to test with all possible desktop 
shells out there (giving poor results either due to the app dev only listing 
environments they did test with or adding shells they haven't tested with but 
which work poorly with the defined actions)

* new shells may arise over time causing a lot of work for app devs should 
they want to join in the fun (alternative: they just ignore the "only in" 

* this opens the door to a cheap way of creating "works better in <shell>..." 
feature sets, which is nonesense

to make life consistent and easy for application developers, i'd suggest that 
if a shell shows these actions, they simply do so in a way that is sensible. 
application developers should be able to sleep well at night knowing that the 
shell does what it does and does it well.

we do this in other areas and it works very well in practice.

tl;dr -> "only in" makes no sense unless the action is actually shell specific 
and not application specific. i'd go so far as to suggest that shell specific 
actions are unmaintanable in practice and would drop that 'feature'

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: <>

More information about the xdg mailing list