Actions extensions in File Manager

[Pierre Wieser]

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

> > On Fri, Feb 26, 2010 at 6:51 PM, David Faure <faure at kde.org> wrote:
> >
> > 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?

I suppose, as I've already proposed to take care of that.
I'm just a little busy these days with my next version...

But, actually, I don't really see the point. Probably, I should have
 missed something.

What do you mean with "instead of adding duplicated keys", or 
"doesn't belong to the spec" ?

Do you mean that if or when the ExecuteAs key will be in DES, we
shouldn't even specify that key in Actions extension ?
-> if so, what about Icon, NotShowIn, OnlyShowIn, or even Exec,
   Path and so on which are already in DES, and have the same
   meaning ?

Or do you mean we should specify it with the usual "same meaning
as in DES" ?
-> this is what we already have done for all other keys in same
   situation ; these are not duplicated keys, these are same
   semantic in another spec, which happend to have same name
   because it was easier at time of writing

Maybe waiting for a DES decision about this key, in order to take
the DES-choosen name, and only this one ?
-> so what about our Tooltip key which has the same meaning that
  the Comment DES key ? It has been renamed because this _is_ a
  tooltip rather than just a comment in a .desktop file

-> and what our SuggestedShortcut key ?
   Doesn't have it also a place in DES ?

I don't think being too tied to DES would be a good thing for the
spec. I'd rather argue we should have our own keys in order to not
 be dependant of any DES evolution which may potentially break some
things in our spec.

And if ExecuteAs is a good name for us, what is the point if DES
happens to choose another one ? We all have already seen multiple
names for one same thing (this is because the alias notion is so
widely spreaded in the world ;-)), so two names in two different
specs should not be a matter ?

So, in the end, though I understand the argument "ExecuteAs has its
place in DES", and I'm willing to propose a patch, I don't understand
the "duplicate key" argument...

Could you please be kind enough to point out what I'm missing ?
Thanks in advance

Regards
Pierre