[Thunar-dev] Actions extensions in File Managers

Discussion:

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

Pierre Wieser

2010-07-19 12:12:58 UTC

Another potential problem of this spec.
When we validate all actions against currently selected files, we can
get a list of valid actions.
However, if an action is also in ItemList of another menu, should we
only show it in that menu and remove it from the context menu, or
show
it both in the context menu of the file managers and the sub menus
defined with ItemList?
Or, in this case, we should set TargetContext=false, so it's hidden
from the main context menu, but can be shown in sub menus since it's
listed in ItemList of another Menu?

Hi,

I agree that the spec let an action be potentially referenced in more
than one place, e.g. as you say, at the level zero of the context menu
_and_ as a subitem of a menu.

I would suggest that in such a case the action be actually shown more
than once, i.e. exactly where .desktop configuration tell us to do so.

In my mind, if TargetContext=false, the action cannot be displayed in
the context menu at all, whether it is at the level zero of the tree or
in a submenu.

Do you agree on that ?

Regards
Pierre

Pierre Wieser

2010-07-19 14:00:23 UTC

Permalink

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

Pierre Wieser

2010-07-19 20:22:52 UTC

Permalink

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

Pierre Wieser

2010-07-19 20:35:52 UTC

Permalink

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...)