Actions extensions in File Manager

[Pierre Wieser]

----- "Jonas Bähr" <jonas.baehr at web.de> a écrit :
>
> We from the Krusader file manager [1] also have our own format for  
> user actions [2,3]. Based on their features I have some suggestions
> too:
> - What do you think about adding a default keyboard shortcut to the  
> actions? If it's already in use by the application itself it will be 
> ignored. If the shortcut is still available but used by two user  
> actions, it well be ignored too. This could be usefull for menus too 
> (provided they are .desktop files on their own, aka "not the KDE
> way").
> - Exec the command as an other user (i.e. as root, equivalent of "X- 
> KDE-SubstituteUID=true" and "X-KDE-Username=root")
> - other options like executing the command in a terminal emulator or 
> to collect stdout/stderr are maybe to application dependent for   
> universal spec.... (a job for "X-Krusader-ExecMode"). However, the DES
> [4] specifies "Terminal(bool)", so maybe you want to allow this key  
> too. "Path" for setting the working directory could be interesting
> too.
> 
> [1] http://www.krusader.org/
> [2] http://www.krusader.org/handbook/useractions.html
> [3] http://www.krusader.org/handbook/useraction-xml.html
> [4]
> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

Well, I have to confess that, for now, I've only tried to specify
the keys Nautilus-Actions already deals with ;-)

But you're right, and keys you are proposing as well as keys
described in DES should be at least considered. This would imply
to add to the profile definition:
- Path: the working dir
- ExecutionMode: a mode to be choosen among some predefined ones:
    'Normal'
        aka a standard GUI
        if we are here, why do not try to also specify
        > start in minimize/maximize/normal mode
        > run in a (maybe new) named workspace
    'Terminal'
        means we have to launch the preferred terminal application
        (which I believe is a desktop preference ?)
        cd to working dir, and runs the command in it
    'EmbeddedTerminal'
        means use a special feature of the file manager
        implementation may fall back to 'Terminal'
    'CollectOutput'
        does this mean that the result of the command will be
        displayed in a dialog ?
        probably also means that the terminal is to be closed
        at the end of the execution ?
    'SeparateStandardError'
        does this mean that two dialog boxes have to be displayed ?
        I'm not sure this is very useful ? Does anyone has a
        use case (i.e. a real action which has choosen this mode) ?

     Maybe we could have, instead of the two last modes, two
     checkboxes:
        [] I do care of stdout
        [] I do care of stderr

- DefaultShortcut
  maybe 'SuggestedShortcut' to put emphasis on the fact that the
  shortcut may have been already used for another thing ?
  But I don't understand what is the use of attaching a shortcut
  to a menu ? Just to open it ?
  It seems rather a established practice to attach shortcut to
  "actions", i.e. to items which actually do something
- StartupNotify
  only relevant when ExecutionMode=Normal
- StartupWMClass
  only relevant when ExecutionMode=Normal
- ExecuteAs

> Personally, I would prefer the alternate way of specifying submenus as
> separate .desktop files. In addition to the advantages you already  
> mentioned, this would also allow conditional menus (the conditions  
> don't have to be repeated for all it's entries).
>
> For the actions themselves I suggest an other key  
> "ToplevelEntry" (bool, defaults to true). This way an action (or menu)
> can give a hint if it is a submenu entry or not. If so, it will not be
> displayed in the toplevel menu. It has to be included in a menu in  
> order to get displayed. (or the other way round: every action which  
> does not set ToplevelEntry=false will be displayed in the toplevel
> menu)
> 
> I don't like the "level-zero" solution you suggest. This means either 
> that there is no way to specify the order of the entires (in the case 
> where a level-zero.directory is not found) or that you have to add  
> every new action explicitly to this file, which is a no-go in my
> eyes.
> 
> I suggest a new key "DisplaySortKey" (string, defaults to the name)  
> which gives a key for case insensitive sorting. This is more powerfull
> then KDE's "X-KDE-Priority" as the toplevel menu entries will be  
> sorted by a string instead of a number, which is much saver against  
> collisions. Entires belonging together won't get separated by  
> unrelated items defining the same priority.
> 
> Example:
> If I define three action for subversion interaction I could give them 
> the DisplaySortKeys "svnCommit", "svnDiff" and "svnUpdate" and they  
> will always be placed together in this order. As soon as I add a third
> one with the DisplaySortKey "svnDiffHead" it will automatically placed
> between diff and update.
> If I absolutely want these entries on top of the menu, I could set the
> DisplaySortKeys to "0svnCommit", "0svnDiff", etc.
> If I have all these svn actions in a special submenu for subversion, I
> can create a .desktop with "ItemList" listing all the actions I have 
> created. This menu should stay in the toplevel, so I set  
> ToplevelEntry=true (or don't define this key at all, since it should 
> default to true) and the DisplaySortKey=svn9Menu. In addition I want 
> to have "update" and "commit" in the toplevel too (in that order, just
> above the subversion menu) to I set their DisplaySortKey=svn1Update  
> and DisplaySortKey=svn2Commit. These two action get also  
> ToplevelEntry=true while every other subversion action will have  
> ToplevelEntry=false and thus not be displayed in the toplevel.
> 
> What do you think about this?

Not very sure, but what I understand is that you are using both
'ToplevelEntry', and 'DisplaySortKey' to build the resulting ordered
tree of items which will eventually be inserted somewhere in the
file-manager context menu.

pro:
I agree your solution is more powerful that 'X-KDE-Priority',
and is able to fulfill the whole issue

con: 
IMHO, this is at a non-negligible complexity cost: we have to
carefully tune each item, setting the right sort key, in order
to get the menu as we want it appears.
Then reordering items may potentially lead to modify all items
at a given level to update their sort key.

Also, I'm reluctant to define two keys just in order to solve
the level-zero issue (as all sublevels are managed by ItemsList
key in menus).

Last but not least, I do think that actions should not decide
themselves where they are inserted in a menu; I do not see any
reason for that as most really important actions are hopefully
already proposed by native file-manager, or OFM, or so.
What we are talking here is actions more or less explicitely
added by the user to better suit his own needs.
What I see when I google for ServiceMenus is that most actions
creators say that _their_ action should be in the toplevel.
Some have submenus, but most time one item at least is in the
toplevel.

As of 'level-zero' proposition, this is just a fake
menu-without-menu, in order to have an ItemsList key. You're
right in that the resulting order of level-zero items is
indeterminated if this file is not found.
Taking your example, do not have a level-zero file might give:

 |                                      |
 +- Update                              +- Commit
 +- Commit                              +- Subversion
 +- Subversion            as well as    |  +- Diff
 |  +- Diff                             |  +- Diff from Head
 |  +- Diff from Head                   +- Update
 |                                      |

Note that Subversion menu itself is of course not unspecified,
as it has its own ItemsList key in its subversion.desktop file.

IMHO, do not display at all unreferenced items would be a no-go.
Just displaying in a unspecified order when order is not specified
appears to me as an acceptable fallback ;-)
Another pro is that reordering items in a UI is pretty easy, as
items themselves are not modified (thus may be read-only), but
only the menu in which they are included is modified.

Nautilus-Actions configuration tool (NACT) is actually pretty close
of ActionMan ([2]). But where items seem to be ordered by categories
in ActionMan, NACT displays items as they will be in the context
menu. So ordering items is just implemented via drag and drop in
the tree view. Pretty easy for the user, I believe.

A second point to consider is that the level-zero proposition
is rather independant of our first goal: having a common spec
in order to share actions.
I imagine an implementation may define anything to have
its own level-zero order, while remaining fully compatible with
the actions defined by the spec.
This is not a small advantage of just do not having any notion
of sorting in the action, doesn't it ?

Two last points I'm not sure they are very clear in the draft:
a) the example above would need five .desktop files:
   - one for each action
   - plus one for the menu.
b) as an item is identified by its desktop_file_id, a given item
   may appear only once in a menu.

> 
> Do you already have any plans for the field codes for the Exec key?
> 

As you said above, we'll have at least to implement DES parameters,
replacing URLs with URIs:
- %f: (first) file name
  but I don't known _how_ an implementation may know if a program
  accept or not multiple file arguments; I think the action
  creator should know if the program accept or not one or several
  file names or URIs; implementation should not have to take care
  of that
- %F: space-separated list of file names
- %u: (first) URI
- %U: space-separated list of URIs
- %i: --icon iconname
- %c: translated label of the item
- %k: URI of the desktop file

plus (from N-A):
- %d: (first) base directory
- %h: hostname of the (first) URI
- %m: space-separated list of basenames
- %p: port number of the (first) URI
- %s: scheme of the (first) URI
- %n: username of the (first) URI

plus (from what I see from Krusader):
- count (of a mimetype ?)

My first thought is to not put any restriction on the command-line
syntax: each parameter is literally replaced by its signification,
no matter how many times it appears in the command-line.
Here also, I think the specification should not try to substitute
to the brain of action creator.

As a second thought, the notation, as a sort of function form,
used in Krusader seems very powerful. Maybe a bit complexe and
potentially verbose, yet (always imho).

Especially, the 'Script', which I understand build the parameters
string at runtime, is very interesting. Do you think it should
be added to the spec ?

> 
> Thanks for the effort of creating a cross file manager user action
> spec!
> 
> Best Regards,
> Jonas
> 

Thanks for your time.
Hope for your next comments and opinions.

Best regards
Pierre

[1] http://www.nautilus-actions.org/?q=node/377