Actions extensions in File Manager

[Pierre Wieser]

----- "PCMan" <pcman.tw at gmail.com> a écrit :

> Some more comments on this spec.
> 
> On Thu, Feb 11, 2010 at 1:43 AM, Pierre Wieser <pwieser at trychlos.org>
> 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.
> 
> As far as I know, this is only supported by Microsoft Windows.
> So I'd suggest drop this part since there is no way to implement it.
> If some specific apps support setting initial window state by command
> line arguments or other specific ways, this should be handled in
> scripts which call those apps, not in this spec.

I have no really good reason to insist to maintain these two states.
May somebody give us some other opinion on the point, please ?

> >> 2. ExecuteAs:
> >>     This should be added to DES rather than file manager actions.
> >>     Please make a patch to DES.
> 
> Post a patch in this mailing list and pray.
> Then hope someday the maintainers of DES may see this.
> I don't know if there is a better way, but this should definitely be
> defined in DES instead of in mime actions only.

I'll try this.
Waiting for an hypothetical DES extension, we'll have to keep this
here for now.

> >> 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.
> 
> I'd suggest you change this behavior in N-A. The rationale is quite
> simple:
> From the view of a general user regarding to usability,
> 
> 1. When the user select multiple files and select one action, he or
> she actually want to apply this action to all files he/she selected.
> Otherwise he or she will only select one file, right?
> 
> 2. If you only acts on the fist file, how do you determine which one
> is the first file?
> 
> 3. Maybe you will use the item that currenty has focus or the first
> one in the list, but from the view of the user, the item is just like
> choosen randomly by N-A and the result is not predictable. This cause
> poor user experience and is a design should generally be avoided.
> 
> 4. Existing N-A can be ported to the new spec by simple converting
> scripts.
> 
> 5. If you try to keep complete backward compatibility with Nautilus
> and N-A, this might be too nautilus-specific and it won't be as
> suitable for others. The possible improvements might be restricted by
> backward compatibility. Then wide adoptation by other projects is not
> very possible.
> 
> 6. Because of 5, there must be some backward incompatibility if you
> want to make this a better spec suitable for all of other DE/FMs. So
> a converting script for old N-A scripts might be needed.

Optimal backward compatibility is just not an option for me.

I don't know what is the situation of PCManFn actions, but I don't
have any way to suddenly decide to convert all existing N-A actions
and scripts in the world.

Though the semantic you describe is right, I have to carefully see 
how to deal with this and what will be the affects.

> >> 5. ShowIfRegistered, ShowIfTrue, ShowIfRunning:
> >
> > Actually I implicitely supposed that all specified conditions were
> > AND-ed. If we need OR conditions, then profiles are here for that.
> 
> If this is your purpose, the key name I think should be:
> OnlyShowIfRegistered, OnlyShowIfTrue, and OnlyShowIfRunning.
> For me, OR might be more useful in realworld apps.
> Is there any real use case for AND?

I even don't have any use case for any of these three keys.
They have been almost directly copied from KDE :)

As keys are AND-ed, I think 'Only' is superfluous, say verbose ?
OnlyShowIn is the only exception because of its presence in DES.
All other condition keys might also be readen as 'Only-something'

> >> 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.
> >
> > From my point of view, scheme is only a string I pass to GIO, or
> > I compare to the relevant part of an URI. I'm far to being involved
> > enough in schemes, protocols and so to be able to initiate such
> > a spec...
>
> Not everyone is using gio. At least KDE and GIO should use the same
> schemes.
> Otherwise things are hard to be cross-desktop and this will make it a
> GIO-only spec.

Yes, and yes. And so ?
I agree that we should be able to rely on an external, widely 
accepted, scheme specification. 
There is surely a RFC for that, don't there ?

More, is using same schemes rather a matter of desktop or of file manager ?
Or a mix of the two ?

We might also decide to define an arbitrary list of schemes, each
implementation being responsible to make the transition between our
internal arbitrary list and actual schemes as used by current
desktop/file manager.

Would this be very more difficult than having a common list of schemes
shared by all combinations of desktop/file managers ?

Regards
Pierre