Actions extensions in File Manager

[PCMan]

On Fri, Feb 26, 2010 at 6:51 PM, David Faure <faure at kde.org> wrote:
> 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
>> spec.
>> 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.
Totally agree. So I still suggest that we patch DES instead of adding
duplicated keys in FM actions.
So, what's the better way to patch DES? Check out the git HEAD and
edit, then do a diff?

> (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
> root).
Those two keys seemed duplicated.
One key named ExecuteAs is enough. If the value is a numeric id, then
this is SubstituteUID; otherwise, it's Username.

>> 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 strongly support that the program must be run multiple times on each
file if it uses %f or %u.
This is how things are handled in glib/gio and LXDE/PCManFM, too.
Randomly choosing one from all the selected files and applying the
action to it is not what the users expect.

>> 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.

Let's patch DES and state this clearly?

> 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.
>
> Phew :-)
> Thanks.
>
>> 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 ?
>
> Yes.
>
>> - 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) ?
>
> Right.
>
>> Nonetheless, I don't see this as a special case, but just an
>> example of a case where the SelectionCount=0 condition is not
>> useless.
>
> 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.

Nice example.

>> > 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 ?
>
> Yep.

Yeah, finally.
Thank you guys for the work. We finally have a usable file actions spec again.
When it's finished, I'm going to implement this for LXDE, too.
So what's still lacking now?

>> > > 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
> packages).
> 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).
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>