Actions extensions in File Managers - Draft 0.12

[PCMan]

This have important use case but only if the spec supports showing
menu items in submenus only.
For example, if you want to create a "Subversion" support for
currently selected files, it's reasonable that you want to put all
supported subversion operations in a submenu since putting them all in
level 0 screws up the UI.

If this is the context menu of selected files:

Open
Cut
Copy
Paste
-----------
Subversion  # a submenu
        Add
        Commit
        Remove
        Diff
        ....
Properties

In this case, we need to add a desktop file for Subversion menu.
Then, we need to add actions for all these items in "Subversion" submenu.
Then, imaging what will happen.
All profiles of "Add", "Commit", "Diff", and all other desktops are
checked to see if they have profiles applied to currently selected
files. It's natural to check whether currently selected files are in
svn repo. So you need to do this check for every submenu item "Add",
"Commit", "Remove"...etc. This is *very* inefficient. Besides, after
that, you get this result according to the spec:

Open
Cut
Copy
Paste
-----------
Subversion  # a submenu
        Add
        Commit
        Remove
        Diff
        ....
Add
Commit
Remove
Diff
...
Properties

All submenu items are added to level 0, too since they all applied to
currently selected files.
With profiles for menus and Target=Submenu; this is completely solved.
We check if currently selected files are in a svn repo in profile of
the "Subversion" menu.
If the files are not in svn repo, show another submenu which only
contains "Add".
For example:

[Desktop Entry]
Type=Menu
Name=Subversion
Profiles=InSVN;NotInSVN;

[X-Action-Profile In SVN]
ShowIfTrue=a-command-testing-if-files-are-in-svn-repo
ItemList=svn-commit;svn-remove;svn-diff;other-svn-commands...;

[X-Action-Profile NotInSVN] # if the files are not in the svn repo
ShowIfTrue=!a-command-testing-if-files-are-in-svn-repo # actually this
is not needed if the first profile doesn't applied, this profile will
be chosen instead.
ItemList=svn-add;

So we can easily provide different menus for files in svn repo and not.
With this, the command testing if files are in svn repo is only run
"once" for the whole menu, not every single submenu item as the
current spec suggests. This greatly improve the efficiency. This is a
real world use case.

Target=Submenu is needed IMO since without this, all items will be
added to level 0 then submenus becomes useless at all.

These problems are found when we tried to implement the spec. If more
examples are needed to convince you, I can provide more.

Thanks

On Mon, Jul 19, 2010 at 10:00 PM, Pierre Wieser <pwieser at trychlos.org> wrote:
>
> ----- "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
>
>