[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Actions extensions in File Managers - Draft 0.12
From:       Pierre Wieser <pwieser () trychlos ! org>
Date:       2010-07-19 20:35:52
Message-ID: 1935899895.152.1279571752370.JavaMail.root () stormy ! trychlos ! pwi
[Download RAW message or body]


----- "PCMan" <pcman.tw@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...)
 
> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]