Actions extensions in File Manager
pwieser at trychlos.org
Wed Feb 10 09:43:02 PST 2010
----- "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
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
> An even more powerful syntax is:
> arg1`;item4.desktop;`command2 arg2`;
> So part of the list is static, and part of it is generated
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.
> 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.
More information about the xdg