Actions extensions in File Manager

[Pierre Wieser]

----- "David Faure" <faure at kde.org> a écrit :
> 
> 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.

Right

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

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

Well, I've re-readen DES, and I don't found this is very clear ?

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"

I so ask: does the system reading the desktop entry should know
how all potentially executable programs will handle multiple
arguments ? 

'%u' parm behavior on a multiple selection is not even specified
in DES.

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

There will certainly be a migration in our implementations.
Keys are different, there are some new conditions and even some
semantics will change. Yes.

But we have to be very careful about how we will deal with "old"
actions, as a new behavior should not break the user system.

Nonetheless, in my own case, which is important for me ;-), I am
thinking that, as I am able to identify old actions, I will propose
at run time to run with old behavior (with the drawback of not being
able to update them via the UI), or to convert them via the management
UI (new format, new semantics, new opportunities).

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

I fully agree

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

Surely, I've badly readen DES :(
Please, could you point out to me where it is specified ?
and, imho, "it has always been" is not really a good reason ;-)

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

This makes sense

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

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' ?

Yes, these are actually two questions..

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

I have to !

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

> 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 ;)

coming soon..

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

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

Well, even if we'd say that this is a short-time spec, we all stay
dependant of developpers available time to implement it. Adding the 
different release schedules of our environments, it is probable that
at a t time, we well have different level of implementation of this
spec.
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.

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

Regards
Pierre