Actions extensions in File Manager
faure at kde.org
Fri Feb 26 02:51:23 PST 2010
On Friday 26 February 2010, Pierre Wieser wrote:
> > Anyway, I don't think this belongs in this spec, if it belongs
> > anywhere then it would be in the DES spec, since one could want
> > the exact same things from an application starting from the main
> > application menu.
> > > > 2. ExecuteAs:
> > > > This should be added to DES rather than file manager actions.
> > > > Please make a patch to DES.
> > Yep, same reasoning there.
> I agree that 'ExecuteAs' key has its full place in DES.
> But I don't believe this should be a "rather than in our spec".
> IMHO, this spec is a derivation, not an extension, of DES. This
> means in my thoughts that this is not because a given key exists
> in DES that it should be automatically taken into account in our
> Each time a key from our spec had the same meaning than in DES,
> we have choosen to use that same key, relying on and pointing to
> the DES. But we do have specified it as a valid key in our spec,
> not because it was valid in DES, but because we needed it.
> So, proposing an 'ExecuteAs' patch should not prevent us
> to specify it in our spec.
My fear is just that at the time of adoption into DES, a different name
ends up being chosen, and then the code would have to cater for both
the "Actions extensions" name and the DES name for the same feature,
for no good reason.
(On top of that, KDE already has code for this, X-KDE-SubstituteUID=true
and X-KDE-Username=foobar, which defaults to $ADMIN_ACCOUNT and otherwise
> from DES, for '%f' parm:
> "The system reading the desktop entry should recognize that the
> program in question cannot handle multiple file arguments, and
> it should probably spawn and execute multiple copies of a
> program for each selected file if the program is not able to
> handle additional file arguments"
OK there's a bug in that sentence, the "if" should be "since" :-)
The %f in there -means- that the program cannot handle multiple arguments,
that's what the sentence means with "should recognize that".
So the end of the sentence means "if %f is there", that's all.
> I so ask: does the system reading the desktop entry should know
> how all potentially executable programs will handle multiple
> arguments ?
You got confused by the "if" at the end of the sentence.
But it's really simple:
If the desktop file says %f or %u then the program handles only one argument so
it has to be run N times, if the desktop file says %F or %U then the program
handles multiple arguments.
If you don't trust me about this, ask the spec authors, I'm 100% sure that
this is what they meant -- I was around at that time :)
> '%u' parm behavior on a multiple selection is not even specified
> in DES.
Missing documentation, but it says that %f is "a single filename" and %u is "a
single URL", so it's rather easy to extrapolate how %u should be handled after
reading %f. Again, I have no doubts there.
> OK, I'm convinced. I admit that this is not for the reasons you stated
> above, but I'm eventually able to deal with the two worlds.
> There is one question left:
> - say we have command 'echo %f %x'
> do we agree that this means that we have to run
> 1) echo f1 x1
> 2) echo f2 x2 ?
> - what should we do when we have e.g. 'echo %d %X' ?
Good question, but I don't think this example makes sense :-)
Either you want one invocation per selected file, or you want one invocation
with all selected files...
The rule we use is "the app supports multiple files/urls if %F, %U, %D or %N is
in the Exec line". %X would obviously be added to that list for this spec. So
I guess the result in practive for %d %X (or %d %F, etc.) would be that the
first arg would be the first (i.e. a random) directory...
How about we actually add the rule to the spec? [ideally in both specs...]
"If multiple files are selected, the application is invoked once per file,
unless its Exec line contains %F, %U, %D, %N or %X"
> > > > 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.
> > ... which we always interpreted as "the folder itself is selected,
> > so let's lookup the actions for inode/directory", I see no real
> > reason for a special case.
> Here also, this is new for me.
> Do you mean you don't do any difference between:
> - user has selected a folder
> - user has selected nothing
> (so I consider that current folder is the currently selected one) ?
> Nonetheless, I don't see this as a special case, but just an
> example of a case where the SelectionCount=0 condition is not
But which other use case is there for SelectionCount?
Oh, ok, I found one. If SelectionCount==2 then show "run a diff between file1
and file2". OK, that's good.
> > I don't follow. The idea is things like Name=Rotate %B ? That's a new
> > idea ;)
> > Not sure this really works well with multiple selection though...
> > You select 50 files and the menuitem is longer than the screen
> > width...
> This may certainly lead to some exaggerations. I see this rather
> as a convenience, with maybe a potential performance drawback..
> To be used with moderation !
Well, the programmer can't prevent the user from selecting 50 files ;-)
OK one useful use case is again "diff file1 file2", I guess.
> Having a common goal is already a great thing, doesn't it ?
> > > level-zero.directory
> > I hope only distros will touch that file, not people installing action
> > .desktop files...
> Humm... Nautilus-Actions configuration tool (yes, I know I often talk
> about it, but this is for now the one I know the best ;-)) let the user
> reorder its actions with menus and so. Distros may propose a default order,
> may even decide to lock it, but imho user should be free to reorganize
> his actions at his convenience.
Sure. My worry is not about users, but about programmers who make a package
that installs one or more action desktop files, and then hack into the level-
zero.directory in order to control the order, and mess up (or fight with other
But ok, distros and end-users-with-a-GUI-tool are already two good reasons for
having that file.
Hmm, but what happens if you install a new .desktop file and level-
zero.directory doesn't list it?
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
More information about the xdg