Actions extensions in File Manager

[Pierre Wieser]

----- "Eugene Gorodinsky" <e.gorodinsky at gmail.com> a écrit :

> Similar discussion here:
> http://lists.freedesktop.org/archives/xdg/2009-August/010914.html
> 

Hi Eugene,

Indeed, a very similar discussion, yes :)

I just didn't found the conclusion of it ?

Last message I find is those of Michael which points out a
potential security hole (I don't understand why, but this is
another matter..)

I understand that there is a sort of consensus about the
'Desktop Action <action>' group in the desktop file, which should
so be reintroduced in the spec, though I'm not sure about the
exact function of 'Actions=' key.

Another consensus about the need of OnlyShowIn/NotShowIn keys when
describing an action. N-A defines the notion of several profiles for
an action, and we may imagine that an application defines one action,
with one profile for each DE. So, I agree with Ted on that we should
have a spec flexible enough to handle most of situations.

But some (and not the least) questions still stay unanswered :

- how many actions in a desktop file : only one, or several ?
  -> I vote for only one, as this is easyer for a sys admin
     to put/drop a file, instead of trying to edit it.
     This way, each file may be seen as a sort of 'atom' of action.

- how to flag servicemenus desktop files :
  with KDE ServiceType, or with a specific path ?
  -> I vote for XDG_DATA_DIRS/subdir
     a) because this is an extension which was already anticipated
        by XDG Base Directory Specification
     b) this eliminate the need for this specific key

- how to avoid to mess up the context menu with many actions ?
  N-A uses an 'enabled' flag, so that the UI may define, update
  and manage a lot of actions, while the sys admin or the (advanced)
  user may enable/disable them as will.

- how to define menus (and submenus, and so on) ?
  PCMan suggested to "standardize" X-KDE-Submenu key, but what about
  the Desktop Menu Specification ? It is actually its perimeter, isn't ?
  I personally find this spec very complicated, but do I should
  ignore it for only that reason ?

- does the spec should define when an action appears, depending of
  current selection or so (mimetypes, basenames, permission, etc.) ?

I believe that extending the current spec is really the first step,
before even decide between an API or a UI or so.. Anyway, there will
most probably be the two, both an API an UI, but both require a spec.

Regards
Pierre