Actions extensions in File Manager

[Pierre Wieser]

----- "PCMan" <pcman.tw at gmail.com> a écrit :

> 1. ExecutionMode seems to be weird.
>     Terminal is already defined in DES by the key 'Terminal'.
>     Minimized or Maximized state of applications cannot be controlled
> by us.
>     It's controlled by window managers. So I don't see any way to
> implement this correctly.

I must admit that I don't know how to implement this. But I see that
some applications insist to start minimized or maximized (and I find
this weird!), so I suppose this is possible.

> 2. ExecuteAs:
>     This should be added to DES rather than file manager actions.
>     Please make a patch to DES.

Well, why not ? Though, as you have understood it, this is not my 
first goal..
May someone give a link to how propose a patch to a XDG spec ?

> 3. ForEach is redundant.
>     Exec key itself can help differentiate this by checking %f, %F,
> %u, or %U.
>     If you need for each, %f and %u should be used in Exec.
> Otherwise, use %F and %U.

This is only right if we consider that we start from scratch.
But at least Nautilus-Actions already has widely spreaded actions.
Today, %f only acts on the first file of the selection. So I'm not 
willing to change this behavior for current users.

> 4. ItemsList:
>     For me, ItemsList=`command to execute`; is more readable than
> GetItemsList=command.
>     An even more powerful syntax is:
>     ItemsList=item1.desktop;item2.desktop;`command1
> arg1`;item4.desktop;`command2 arg2`;
>     So part of the list is static, and part of it is generated
> dynamically.

This would suppose that each part of the ItemsList is to be
evaluated at run time, at least to see if it is a fixed string or
a command to be evaluated.
If we are willing to support the inherent cost of such a behavior
(which eventually may be a user choice), I'm afraid that at least
N-A is stucked to GLib and its  g_shell_parse_argv() restrictions.
To not let the user suppose an actual shell is run, I'd prefer a
special syntax, as [..] or something like that.

Also note that the actual syntax in your example would be:
ItemsList=item1;item2;`command1 arg1`;item4;`command2 arg2`;

> 5. ShowIfRegistered, ShowIfTrue, ShowIfRunning:
>     What will happen is all of them are defined in the action, but
> each of them gives opposite result?
>     Are those keys mutual-exclusive, or should be combined with 'OR'?
>     The default state of action should be visible to the user if
> NoDisplay or Hidden are not true.
>     But when ShowIfTrue is defined, it implies that if this returns
> false, the item should be hidden. I guess when those three keys are
> defined together, there results should be combined with boolean OR.
> If
> the combined result returns false, the item should be hidden. This
> should be addressed in the spec.

Actually I implicitely supposed that all specified conditions were AND-ed.
If we need OR conditions, then profiles are here for that.

> 6. SelectionCount:
>     When will we have a condition that SelectionCount=0?
>     Aren't those actions applies to selected files only?

Well Nautilus has an extension API which applies when there is no
selection (get_background_items). So when SelectionCount=0, then
the actions apply on the current folder.

> 7. Schemes:
>     We need to initiate another "Desktop Schemes" spec to define some
> standard schemes.
>     Non-standard schemes like computer:///, trash:/// or smb:///
> should be well-documented in specs.