Removing OnlyShowIn / NotShowIn from desktop actions

[Aaron J. Seigo]

On Wednesday, July 3, 2013 15:53:40 Sebastien Bacher wrote:
> (I don't have specific examples in mind, but I can see it being used for
> desktop specific features or e.g when different desktops have different
> design views on what items should be exposed in their UI ... imagine an
> IDE, you might want have a list item "start Qt project" and "start KDE
> project" under KDE and "start GTK project" under GNOME or XFCE)

hopefully such use cases are the exception.

in the specific example given, i really don't understand why a "start Qt 
project" would have anything whatsoever to do with the shell. this idea that 
"application development framework is tied at the hip to the shell" is a 
disease. nobody cares except for those of us working on desktop environments, 
and that's precisely why we shouldn't care about. people just want 
applications that work. everywhere. period.

assuming there are rational use cases, i would expect one of two things to 
happen:

* for such actions to only be implemented in .desktop files that have 
OnlyShowIn=  in the Desktop Entry section, marking the entire application as 
shell specific (we have identified numerous valid use cases for this, and i can 
see desktop action extensions fitting mostly in those same use cases)

* for such actions to be implemented in .desktop files that are not in the 
general application menu hierarchy but in a shell-specific location

basically, i expect that all shell-specific actions would come only from shell-
specific processes. which makes "only in" implicit, and obviates the need for 
an explicit setting feature exposed to all app devs.

real world examples to the contrary are welcome.

>  what's the
> issue with keeping it as an option is somebody feels like the need to
> use it?

because once offered people will use it, and given that it is almost never 
appropriate to use people will use it innapropriately. that's just how 
software developers are :)

and the sins of the application developer are paid for by the user.

as this is a preventable sin, simply by not providing such support in the 
standard, as framework developers we'd be doing our users a great big favour.

iow, for the nascent (and currently non-existent) use cases we may dream up, 
it is already being misused right now in the real world (see the transmission 
example in the OP). it seems apparent that harm outweighs benefit in this case, 
so dropping the feature makes sense imho.

-- 
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/028e3f34/attachment.pgp>