Removing OnlyShowIn / NotShowIn from desktop actions
Aaron J. Seigo
aseigo at kde.org
Wed Jul 3 08:29:27 PDT 2013
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
* 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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the xdg