[Thunar-dev] Actions extensions in File Managers - Draft 0.12

[Pierre Wieser]

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

> After trying to implement this spec, I have some suggestions.
> Actions (desktop entries with Type="Action") and menus (desktop
> entries with Type="Menu") are actually very similar.
> The only difference is that an action takes "Profiles" and a menu
> reads a "ItemList".
> Why not just merge them? For example:
> 
> [Desktop Entry]
> Type=Action or Menu
> Name=name
> Icon=icon-name
> Tooltip=tooltip
> Profiles=profile1;profile2;  <--- applies to both action or menu.
> # ItemList is defined in profiles, not here.
> 
> [X-Action-Profile profile1]
> OnlyShowIn=LXDE;GNOME;XFCE;
> Exec=command line # This is only valid when Type=Action
> ItemList=item1;item2;item3; # This is only valid when Type=Menu
> 
> [X-Action-Profile profile2]
> TryExec=try_exec
> Exec=command line # This is only valid when Type=Action
> ItemList=item1;item2;item3; # This is only valid when Type=Menu
> 
> In this way, both of the actions and menus can be validated against
> different conditions and have different profiles.
> In your original spec, menus don't have profiles. However, after
> trying to implement this spec, I think this is a required feature.
> With these modifications, menu and action become the same object. The
> only difference is in "Type" and their profiles.
> Profiles of "Action" defines Exec and that of "Menu" defines ItemList
> instead.
> 
> This greatly simplify the spec while make it more featureful at the
> same time.
> Please consider this. If a patch for this spec is needed, I can create
> one.
> Since I don't have the source file of your spec, I cannot do it now.
> Hope you can understand what I'm talking about.
> 
> Cheers!

Hi,

I understand that you are proposing to extend the 'profile' notion to
menus, so that a menu may have several profiles, each profile having 
its own set of conditions, along with its own set of subitems.

I suppose that, as for actions, only the first valid profile, regarding
the currently selected files, will be considered, thus determining the
current list of subitems.

I am not really convinced that this would simplify the spec
(after all, we are adding here another level of somewhat as an
indirection), nor the implementation itself (but this is rather a 
point of detail).

If I agree that this seems bring up more potential to the spec, the only
benefit I see is having different menu order in different conditions. Not
sure this will be a great benefit for users (and I thought that dynamically
changing order of items in a menu was almost always forbidden by human-
machine interface specifications ?)

Do you have envisaged another sort of use case ?

Contrarily, I am afraid this will not help us for debugging when a user
will complain that "my action does not appear in the menu"...;-)

>From my point of view, trying to make action and menu the same object
is just useless. They _are_ different because they have different 
behaviors.

>From an implementation point of view, they are similar enough to share a
common base class. However I am not willing to spend any effort just to do 
them more similar...

There are pros and cons. For me, these are rather pro and cons ;-) And,
finally, I am not sure at all that this pro is worth the added complexity..

Regards
Pierre