GNOME Bugzilla – Bug 495875
right-click menu reordering
Last modified: 2013-09-13 00:59:59 UTC
Currently the right click menu of every component looks different even though there is a lot of common elements. It doesn't feel right. To follow a "draft" patch to fix items of most plugins I could test (not exchange or groupwise unfortunately) I also have to get back the paper where I wrote down the ordering logic.
Created attachment 98913 [details] [review] evolution-right-click-menu.patch addressbook/ChangeLog | 5 + addressbook/gui/component/addressbook-view.c | 12 ++-- calendar/ChangeLog | 7 ++ calendar/gui/calendar-component.c | 6 +- calendar/gui/memos-component.c | 6 +- calendar/gui/tasks-component.c | 6 +- mail/ChangeLog | 5 + mail/em-folder-tree.c | 27 +++++----- plugins/folder-unsubscribe/ChangeLog | 5 + plugins/folder-unsubscribe/org-gnome-mail-folder-unsubscribe.eplug.xml | 2 plugins/mail-account-disable/ChangeLog | 5 + plugins/mail-account-disable/mail-account-disable.c | 4 - plugins/mark-all-read/ChangeLog | 5 + plugins/mark-all-read/org-gnome-mark-all-read.eplug.xml | 2 14 files changed, 73 insertions(+), 24 deletions(-) thanks for considering.
I like the idea and patch seems to working fine, just add bug reference to ChangeLogs and commit to trunk. I only have one question, what do you think about unification of action numbers? Like: "10." for New... "20." for Move and Copy items "30." for Save... "40." for Delete... "99." for Properties? Or maybe 20 between each item type? You know, regardless of component, same type of event will have same number. Does it sound good?
ok based on the right-click left panel menu only, and trying to minimize the changes wrt to the current numbers: 10. New 11. Open ? 11->13 possibly new related items 14. Save 15. Copy 16. Move 17->29 err what else ? 30 - bar 30. Delete 31->39(other delete related items, in the sense of removing, destroying, erasing and the like, not recover for example) 40 - optional bar (to help reduce targeting problems) 41 -> 90 various items of the current component 99 - bar 99. properties following this logic could also help sorting "in-component" menus. Those could also benefit from a little stripping as some items in them might seem redundant (copy/cut/past for example) or the list just overly long.
a) I'm not sure if it's good idea to have them so close (10-20), when someone will need to place there more than one item and do not want to dig names (or relay on names), then it will be better to have a hole between numbers, I think. b) Why did you create a hole between Open and Save? I usually see something like New/Open/(Close?)/Save/Save as/... (I know, it's against my a), but I hope you know what I mean.) Otherwise sounds good to me, go a head ;)
for a and b: "and trying to minimize the changes wrt to the current numbers" so I don't have to scan all bits of evolution to check if something is misplaced at this stage. I'll throw a pointer at this bug on the mailing list to get more comments and eventually create a page on the wiki for reference. commited at revision 34548, closing.