Removing OnlyShowIn / NotShowIn from desktop actions

[Dylan McCall]

On 3 July 2013 10:18, Sebastien Bacher <seb128 at debian.org> wrote:
>
> Le 03/07/2013 17:12, Jasper St. Pierre a écrit :
>
>>
>> Why shouldn't an application be able to start a KDE project under GNOME?
>
>
> Because if your IDE know about 15 types of projects you probably don't want your desktop lists all those, in its context menu, but only favor the ones you recommend. Users who want to change from the default/recommendation can tweak their launcher or open the IDE and start a project rom there

I don't understand why anyone would use (static!) desktop actions for
that kind of stuff in the first place. Most IDEs I have encountered
are very modular, very configurable, and have a pretty big assortment
of possible project templates. Just to begin with, I think it's a huge
over-simplification to assume that the user's current desktop has
anything to do with what type of software he is likely to build. (And
that can really only be applied to an IDE in the first place, which is
a pretty specialized application). I'm using GNOME Shell, but a month
ago I was much more likely to be building a web project, an Android
project or an Ubuntu Touch project. The only thing that can provide a
decent interface for choosing the right template is the IDE itself,
and a flat menu (which is the only thing Desktop Actions can really
describe) is never going to work for that anyway. Further, there's no
real reason to get so specific at that stage, since all we're doing is
postponing the inevitable "describe your project" dialog. Having all
those specific project choices in said flat menu will save, what, half
a second in the 60 seconds of setup for a six+ hour development
project? I think it makes considerably more sense to replace "Start a
$template project ×√10÷n" with "Start a project", and have that open a
dialog to start a project. Maybe even a nice dialog. Heck, if the
specification can actively prevent bad design, I think it should do
that with passion ;)

Now, a nice IDE might highlight particular (frequently used?) project
types in its own main menu, but that's dynamic, and Desktop Actions
are static; set in a static file that is created when an application
is built, independent of configuration changes like whether the user
has just uninstalled valac and gnome-devel or even who the user is. I
remember there was a GNOME Shell extension at one point that showed
recently used files (via Zeitgeist) in the context menu for an
application, so I wonder if that sort of thing could maybe be expanded
on as _the_ way to dynamically add actions to launchers (and also act
as a service for applications themselves), but I'll be surprised if it
makes any sense for that to affect Desktop Actions. I'm worried that
would dramatically alter the scope and complexity of documenting,
building for and implementing these (rather distinct) ideas, which
would be a bit of a shame.

--
Dylan