Actions extensions in File Manager

[David Faure]

On Wednesday 10 February 2010, Pierre Wieser wrote:
> ----- "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.

Two things:
* in KDE we can implement this using kstart
* the application itself can use NETWM to do this kind of things better,
but then of course it's not the user's choice anymore. But this means
the problem we're potentially trying to solve here is "users want to start 
some application minimized or maximized", not "some applications insist on 
starting minimized or maximized", they can already do that in code.

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.

> May someone give a link to how propose a patch to a XDG spec ?

Seems they all moved to git now so it should be easier.

But this is definitely not a blocking point for moving forward with the action 
extensions spec IMHO.

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

Yes. This is exactly how DES works.

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

I strongly disagree on this point. If we're working together on making a 
common spec, we have to accept that there will be a migration from our 
respective current solutions towards the shared standard solution. Some 
actions will have to be fixed, just like they all need to be installed 
somewhere else anyway, no? (That's certainly the case in KDE, which solves the 
migation problem: for some time we can just support old and new actions in 
different dirs, and support different keys in both).

I object to defining a bad spec that keeps old hacks from the past into it.
If there's *one* point in time for cleaning up old hacks, it's the switch to a 
new file format spec.

%f doesn't mean (first) file name, it means "one file name at a time", running 
the application N times if multiple files are selected. This is how it has 
always been in DES, there's no reason for the popupmenu actions to work 
differently from the standard "LMB click or RMB/Open With" way of starting 
applications for a bunch of selected files.

On top of that, the reasoning is flawed; you say "Today, %f only acts on the 
first file of the selection. So I'm not willing to change this behavior for 
current users" but such a behavior for %f would indeed mean a change of 
behavior for other users, like KDE users. So the compat breaks somewhere 
anyway, so let's choose a standard behavior that makes sense. The notion of a 
"first selected file" doesn't make sense in a GUI app, and doesn't match what 
people would expect from running an action on N selected files.
=> Please remove (first) everywhere in the Parameters table.

> > 4. ItemsList:
> To not let the user suppose an actual shell is run, I'd prefer a
> special syntax, as [..] or something like that.

I don't actually understand what the stuff inside [] really is. Could you add 
an example in the spec?

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

> > 7. Schemes:
> >     We need to initiate another "Desktop Schemes" spec to define some
> > standard schemes.

Different topic, not for this thread.

> > 9. Parameters:
> >     Please explain the use case of %w and %W.
> >     I doubt this is rarely needed.
> 
> I agree with you. But this is a request of some users to be able
> to get names without extensions. When making them enjoy is so easy,
> why do I go without it ?

I guess the use case is like Exec=pdftops %f %w.ps
in order to get a command-line like "pdftops foo.pdf foo.ps" in the actions 
for foo.pdf. Makes sense to me. Could be added to the spec as an example ;)

> >     Besides, those parameters should apply to any key in this spec
> > requiring a command line, not only the Exec key. This should be
> > addressed in the spec.
> 
> But, they do. In most keys if not all (Name, Tooltip, Icon, etc.).

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

> I have seen this spec rather as a long-time target, rather than a
> "all must be done now" !

Hehe. I remember the same debate when working on ODF: a "common denominator 
spec" vs a "union of all features spec".
From an implementor point of view, it's nice to have a spec that includes all 
possible features we might come up with, so that different implementors don't 
start having similar extensions with different names, but use standard names 
instead.
From a user point of view (one who is writing .desktop files for multiple 
desktop environments), it sucks, because you don't know what is going to work 
on all desktop environments, if the full spec is not implemented.
This leads to ideas like modular specs with a minimal core and optional 
modules on top, but I'm not sure we want all that complexity here, this spec 
isn't -that- complex.

> > As more and more desktop files are installed for those actions,
> > parsing requires more and more time. Is there any better way to cache
> > the parsed result to speed up loading, just like what
> > desktop-file-utils does?
> 
> I'm not sure to well understand what you mean.
> Desktop files are not supposed to be parsed each time we have to display
> a context menu. We surely have a list of objects in memory, don't we ?
> Contrarily, each condition, each parameter must be re-evaluated each time
> we want display a context menu (because it depends of context ;-)) and the
> selection has changed.

This still makes the very first popupmenu in the application quite slow to 
appear, if it has to parse N desktop files. But we already live with that; 
actually we parse these files every time currently, and it's not that bad.
(BTW, remember that if you keep a representation in memory you also need to 
watch the directories for changes, otherwise people have to restart the 
filemanager in order to see their newly installed action definitions; not very 
user-friendly). Well, I'll need to think more about implementation later, 
let's finalize the spec first ;)

> level-zero.directory

I hope only distros will touch that file, not people installing action .desktop 
files...

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).