Actions extensions in File Managers - Draft 0.12

[Pierre Wieser]

----- "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

There are two things in this case.

First is the layout of the items.

I agree, and I apologize, that the spec is not clear at all on this subject.
In my mind, items that may appear at level zero come from only two sources:
- they are explicitly listed in the level-zero resource (see Appendix A)
- these are items which are not listed elsewhere (i.e. in any menu).

As you emphasize it, there is no sense of displaying at level zero an item 
which is already defined as a subitem of a menu

In other words, it should be enough for any item, action or menu, to be listed 
as a subitem of a menu, to not be displayed at level zero. A supplementary flag 
in this item, saying "yes, I really want this to be a subitem" appears useless 
to me as soon as the item is listed in an ItemsList key.

(This appears "natural" to me because this is a direct consequence of menus,
not of "desktop file extension for actions in file managers". And menus exist
since several versions in Nautilus-Actions.)

Second is the efficiency of the filters.

I agree that your example may make sense at first glance :) Though I am not
conscious of any action I may want on _all_ items but those in a svn checkout..?

I just have a remark: to get a better efficiency when applying the 'svn' filter,
you agree on one of:
- having the same standard menu (as items may or not target svn files, say 'A menu'),
  with completely different set of subitems; I think this might be a bit perturbing, 
  don't you ?
- having a personnalized menu (say 'Subversion menu' vs 'Non Subversion menu'),
  making use of dynamic capabilities of Name, Tooltip and Icon keys, thus suffering
  of some sort of supplementary computing to get these features..

Without profiles in menus, you would just have defined two distinct submenus,
applying twice the 'svn' filter. Or, more probably, only once for the Subversion
menu, plus another filter for the non-subversion one, as 'is this saveable' or
'is this a component for tarball', or something else...

And I have to disagree: the spec clearly states that conditions set on a menu
apply to all subitems. If the spec suggests a different thing, then say me where
as this is an error.
Yes, the spec also states that each subitem is individually checked. Of course,
for conditions set on each subitem. It is up to the action designer to "factorize"
the needed conditions.

So.

If you are OK, I propose to review the spec for the first point, as I agree it is 
not clear enough about the layouting (?) of the items. I may prepare a 0.13 version
to better specify:
- how the level zero should be built
- that an item may be addressed more than once
- that an item addressed in a submenu should not appear (but explicitly addressed)
  elsewhere

About profiles in menus, I am not yet convinced. I agree that there may be some use
cases, but being able to use this feature does not mean this feature is required ?
So, yes, other arguments are welcomed.

Regards
Pierre