Community
Participate
Working Groups
Let's use this bug to collect improvements planned for the Mylyn 3.0 cycle.
*** Bug 193845 has been marked as a duplicate of this bug. ***
The following sections of the Eclipse "User Interface Guidelines" document provide recommendations for a common order for menu commands: http://wiki.eclipse.org/User_Interface_Guidelines#Context_Menus http://wiki.eclipse.org/User_Interface_Guidelines#Menus_2 http://wiki.eclipse.org/User_Interface_Guidelines#Context_Menus_2
We should investigate using the org.eclipse.ui.menus extension point that was introduced in Eclipse 3.3. It should enable us to get rid of a lot of the manual population of context menus: http://wiki.eclipse.org/Menu_Contributions
+1 It would be great to get rid of that custom extension point.
Mik, can you please remind me again why object contribution can't be used there?
(In reply to comment #5) > Mik, can you please remind me again why object contribution can't be used there? The task editor is not an element selected in a viewer, so instead we do the equivalent of what we would do if it was. As per the note in the code I'm sure that there's a better way (e.g. comment#3).
Workbench had an API to populate menus automatically probably since before 3.0. See IWorkbenchPartSite.registerContextMenu() and org.eclipse.ui.popupMenus extension point. Selection provider passed to registerContextMenu() is used to determine object contribution, so editor could just provide corresponding ISelectionProvider implementation.
"Clone task/query" action may make more sense under the "New" submenu then under confusing "Operations" submenu
(as per request of Mik, cross-posting my comment under bug 220364 as input for the 3.0 improvement discussion) [...] the whole task list context menu might benefit from some reorganisation, so here's my 2 cents after a few weeks of Mylyn+Tasktop: - The "move" menu seems to "symlink"(?) tasks from remote repositories into other local categories/queries; clone seems to do it into remote task repositories? I'd expect them together, and maybe separate from the schedule for/mark as items? - I actually have no idea what "copy details" will do, just starting trying it a bit (I'd expect a "paste" or so with it, or a task-level "cut-copy-paste" set) - I'd separate the import/export of tasks and queries, maybe make that a "Import/export" item rather than "operations"? - I'm actually somewhat confused on the difference between categories and queries in terms of how I use them to group tasks, and how they deal with tasks within them: pressing delete always makes me read the popup to make sure it will do what I expect (in other words: my expectation of what will happen when I select "delete" is not always 100% deterministic, especially with the "remove from category" option next to it) - Likewise: I can create a "new local task", or a "new task" and then select "local tasks" as the repository. It saves a click or two for adding local tasks, but adds a little confusion maybe as well. Hope this is useful :-) (I haven't checked the context menu guidelines links above yet myself)
Yes, clone is most likely destined for the New submenu. But before doing that I want us to figure out where to put the Import/Export stuff. I wonder if it's OK to have a menu entry called "Import/Export"? I'm not sure if you're allowed slashes in menus, maybe it's worth trying out.
(In reply to comment #10) > I wonder if it's OK to have a menu entry called "Import/Export"? I'm not sure if you're allowed > slashes in menus, maybe it's worth trying out. Source / Surround With / Try/catch block
The move of clone actions to "New", and renaming of "Operations" to "Import/Export" is done. We can consider additional changes in the 3.1 cycle.
We should also review the search view menu. I have made some modifications to the ordering of elements.
Here's the design from our last call. New Task pull-down: * No default repository, use the current selection for the default action. If no selection, create a local task. Or always create local tasks. * Only show repositories relevant to active working set. * Then show New Query, New Category, after separator. Popup menu: * "Mark as" is missing icons * Copy Details becomes a submenu, with default copy action bound to Ctrl+C * "Schedule for" and "Mark as" go to the new section * Remove "Import and Export"? Need to design import/export story. Task editor menu: * Get rid of undo/redo, RCP apps might need to put this on a toolbar
I have restructured the menu of the task list, task editor, active task link, and task trim per our discussion on a conference call. The code that constructs the menu is in RepositoryElementActionGroup and is now shared between the different UI parts. I have fixed the enablement of the context and mark as menu. These should now show up consistently in the task editor.
Created attachment 137743 [details] mylyn/context/zip
Some additional streamlining: * Moved Schedule For menu above Mark as * Added New > Subtask menu to Task Editor
Fixed: * Enablement of Mark as menu for local task editors * Enablement of Delete action * Menu for active task link when no task is active
Also enabled the Mark Complete/Incomplete shortcuts in the task editor.
Fixed: * Activate Action and Deactivate action did not operate on active task when activated from the active task hyperlink
Steffen: I'm finding that Context is in a weird spot when using it in the editor. Why not move it to the same section as "Move to"? The "Import and Export" and "Repository" can go there as well (afaik those only popup from the Task List). In other words, we end up with submenus in only two, not three spots in the popup menu.
Yes, that makes sense to me and avoids an extra group. I have committed the change.
Steffen: I'm finding that everything is working well except for the Copy actions. I do miss having a good default copy action in the main menu.
Can you file a new bug and make a suggestion how to fix that? I have been getting fairly used to navigating the menu by now but it did take a few days.
It can wait until the next UI review. I don't have any great suggestions.
While the org.eclipse.ui.popupMenus extension-point has not been deprecated for 3.3 it is my understanding that it is recommended to use org.eclipse.ui.menus instead.
