Actions extensions in File Managers - Draft 0.12

[PCMan]

A con of current spec is that every menu applies to all selected files
unconditionally and it's the responsibility of the implementor to
remove the menus from UI if they are empty.
However, in real world use cases, the menus are actually needed by
some types of files only. So for me it's quite natural to have
conditions associated with menus.

For example, an "Extract" menu containing "Extract Here" and "Extract
To..." should only apply to files with mime-type:
application/x-zip-compressed, application/x-tar-compressed, and other
compressed files.
Applying this "Extract" menu unconditionally to all files and then
check if the menus contain no items later makes less sense then
associating conditions with menus since apparently the menu is only
used by compressed files. So why not set a condition for the menu
instead of evaluating every submenu actions and to check if the menu
is empty and remove it from the UI?
On the contrary applying conditions to menus solve this easily and
efficiently. Even no new source code needs to be written if you reuse
the code written for actions carefully.

For context menu, sub menus and level 0 actions are actually the same
thing. They are items in the context menu. One has a command
associated with it by Exec key and another has a ItemList associated
with it. Other parts are totally the same and the share all the same
properties. I see no reason and no advantage to treat them as
different objects. At least when I try to implement it this way I
found it very easy and efficient.

Comments are welcomed.

On Tue, Jul 20, 2010 at 4:35 AM, Pierre Wieser <pwieser at trychlos.org> wrote:
>
> ----- "PCMan" <pcman.tw at gmail.com> wrote:
>
>> 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
>
> Humm..
>
> I have another con argument.
>
> To take back your example and extend it, we can view that grouping actions
> in a menu when they are relative to the same sort of target (here, svn)
> is some sort of user-friendly optimization, even if they did not have been
> created by the same designer.
>
> It so becomes easy to share all svn actions, in a common menu (say 'svn'),
> as a set of .desktop files.
>
> Mixing in this same menu other actions which do not have the same target will probably not make easier the share of these actions...
>
> (I'm afraid my english becomes worst at each sentence :( - Sorry...)
>