Actions extensions in File Manager

[Pierre Wieser]

----- "Ted Gould" <ted at gould.cx> a écrit :

> I'm a bit confused about this, it seems that you're proposing a few
> ways of doing it in that document.  Shouldn't we choose one? 
> I personally like storing everything in a single .desktop file.

This is probably because (maybe wrongly) I mix in the draft some 
rationales, try to describe existing and possible solutions. Actually
I do propose the alternate way of creating a hierarchy of actions.

About storing everything in a single .desktop, I understand that
this make easyer to package and distribute. Is there any other
advantage ?

Contrarily, I see some drawbacks:
- this create a new notion, a group of action
- in a UI management, when creating a new action, the user is
  required to decide if this action should be saved in its own
  .desktop file or in an already existing one.
- actions written in a same .desktop are not individually adressable
  (but specifying a compound id which would be
   <desktop_file_id>-<action_id>)
- we have to specify in the [Desktop Entry], not only the ordered
  list of actions, but also if they should be gathered in a menu
  or not
- last, if actions have profiles (see below), the .desktop file
  will be much more complex

> I'm also a little confused by the name "Profile" -- why was it
> changed from "Action" in the previous versions of the desktop spec.
> That made more sense to me.

Actions do not have been renamed to Profiles.
Instead, I have distinguished in the action:
- an invariant: label, icon, tooltip
- some conditions, the command and its parameters, which I've called
  'profile'
Then I say that one to several profiles may be defined for an action,
but, at runtime, one the first profile whose conditions are met will
be selected as candidate for the context menu.

Most of actions/services menus I've seen has only one profile.
Say, for example, an action 'Open terminal here', with following
three profiles:
- if selection is a directory, open a terminal in that directory
- if selection is a file, open a terminal in base directory of the file
- if selection is the desktop, open a terminal in ~/Desktop

We could also have three actions 'Open terminal here', each with
ad-hoc conditions so that only one action may be candidate at one
time. But in the management UI, these three actions with the same
label would be a bit disturbing.

We could also have three actions, with slightly different labels,
say 'open terminal in this directory', 'open terminal if parent directory'
and 'open terminal on desktop', but this appears as just a work-around
for this issue.

At last, it appears that we have one conceptual action, and several
ways of doing it depending of runtime conditions.

> 
> 		--Ted

Regards
Pierre