Community
Participate
Working Groups
The context menu of the navigator does not show the action's icons.
Created attachment 2603 [details] showing the different changes
Created attachment 2604 [details] fixes Implementation notes: ResourceNavigatorActionGroup - pulled up getImageDescriptor() from MainActionGroup; changed visibility to protected MainActionGroup - commented 3 lines because the neccessary images don't exist yet, s.b. SortAndFilterActionGroup RefactorActionGroup GotoActionGroup WorkspaceActionGroup - needed access to getImageDescriptor() PropertySheetPage - the menu showed exactly the same 2 actions which are already on the action bar as buttons -- the menu is therefore redundant; the bookmarks view doesn't show a menu so the menu is not necessary for "consistency" either Tasklist - changed order of "Sort" and "Filter..." to be consistent w/ Navigator view. Todo: The following icons have to be created an the lines in MainActionGroup#makeActions() have to be uncommented afterwards: clcl16/collapseall.gif clcl16/synced.gif dlcl16/synced.gif
Sebastian, We intentionally do not show icons in context menus for several reasons: 1. when menu items also have check boxes or radio buttons, the menu ends up appearing too wide, 2. having too many icons is visually distracting, 3. we want to minimize the number of graphics resources allocated (and the time to load them) While we appreciate your initiative in trying to fix PRs, it would be best to check with us first to ensure that your efforts mesh with the project goals. Thanks, Nick
Please do the following: Import org.eclipse.ui.views (and its required plug-ins) into an empty workspace and start this "minimal" Eclipse. Create a project. Create a bookmark. Create a task. Open Bookmarks, Tasks, Properties and Navigator view. Right click on a task in the Tasks view ... observe: context menu shows the same icons as the main menu/toolbar. Right click on a bookmark in the Bookmarks view ... observe: context menu shows the same icons as the main menu. Click on the project; then right click on info/editable in the Properties view ... observe: context menu shows the same icon as the main menu. Take a look at the Navigator context menu and observe under "New.." icons will be shown for Project/Folder/File/Other... The Navigator view is the _only_ view -- from the basic views -- _not_ showing icons. So from a "consistency" standpoint: Either rework the context menus of Bookmarks/Tasks/Properties not to show the icons or show the icons on the Navigator menu. @@@@ On load times/memory footprint -- the Edit/Paste/Cut icons are so common (i.e. will be on a lot of menus -- copy will be on almost every context menu) they could be ISharedImages. With Cut/Copy/Paste icons it should either be "show them everywhere" or "show them nowhere" but not "show them in this menu but not in that menu". @@@@ As it is right now, Eclipse's context menus are quite inconsitent -- some views populate their actions w/ their respective icons (from main menu/toolbar), some don't. @@@@ Looking at http://www.eclipse.org/articles/Article-UI-Guidelines/Contents.html I couldn't find a reference why not to show the icons.
The changes in PropertySheetPage and TaskList are not dependent on the "contex menu" issue.
I agree about the (in)consistency. Most context menus already have icons. The Navigator context menu already seems to have (some) empty space where the icons would go. Some JDT context menus have the same problem. The Outline View does not have any icons. The Java editor context menu has icons for some actions. It does not have icons for cut/copy/paste.
I would go ahead and add the icons to JDT too ... But I wait for "go" :) I think the descision on cut/copy/paste images as ISharedImages is the main blocker on how to implement it.
I've asked the usability folk for guidelines here. In the meantime, we can fix the inconsistency. Knut, could you please review Sebastian's changes. We should also add more common icons to ISharedImages. See bug 26423 as well.
Both members of the usability team feel that icons should be avoided on context menus because they add unneeded visual clutter, in addition to the other reasons above. For now, we should fix the inconsistency by adding icons in the Navigator, but we should be sparing in how many icons we include. The guidelines should be updated with this recommendation. JFace needs to support this better, so that the same actions can be reused whether in a toolbar, pulldown menu, or context menu, even if they specify an image.
Sorry, we were not able to look at your patch for M4, but will do so in M5.
No problem ;)
Entered bug 29914 requesting new icons for collapse all/sync with editor. Go Back/Forward/Up already have icons. Go to resource does not use the icon, presumably because it only is in the pull down menu and not in a context menu or toolbar.
Released all changes except for GotoActionGroup. Need to investigate why go to resource icon is not used. Made some minor modifications to use all three kinds of icons (disabled,enabled,colored) if they are already available.
Knut, in the Properties view, we can't remove the categories and filter actions from the view menu. They need to be there for accessibility.
The bookmarks view should also have a view menu then.
Some thoughs: Shouldn't every button on the action bar be on the view menu then? If so, the "Add Task" and "Delete Task" from the Task view e.g. should be placed on the corresponding view menu also -- the key "Delete" maps to "Delete Task" but "Add Task"? Isn't there a way to make the buttons "accessible" on the action bar? If not the action bar's "function" would be reduced to "provide the commonly used functions of the view menu for quick access".
I found an answer to my first question in the UI guidelines: "Any action which appears in the toolbar [of a view] must also appear in the menu" above 6.12. @@ To be consistent the following views should be updated then: "Add Task" & "Delete Task" should be placed on the view menu of the Task View "Restore Default Value" -> Properties view menu "Back", "Forward", "Up", "Sync w/ Editor", "Collapse All" -> Navigator View menu "Delete" & "Go to" -> Bookmarks View menu (doesn't even have a menu yet) @@@@ Remains the question if we want to force creators of views to have a view menu even if they have only one action (or a very small number) for their view. Properties View (3 buttons/2 menu items) <-> Bookmarks View (2 buttons/no menu items). Under the guideline above both views would have to be adjusted.
From looking at existing views I would have thought the guideline is that tool items that are neither on the view context menu nor the main menu bar need to be in the view menu.
Nick, please see the previous couple of comments regarding view menus. The guideline does not quite match reality and I wonder if it is still correct.
Knut's assumption in comment #18 is correct. The requirement for accessibility is only that an action on a toolbar also be accessible via -some- menu, not necessarily the view menu. So if it's on the main menu, or the context menu that's fine. The context menu should be used for items that apply to the selection or particular items in the view (i.e. new item). The view menu should be used for settings that affect the presentation of items in the view, not the items themselves (sorting, filtering, etc.). To address Sebastian's concerns: "Add Task" & "Delete Task" should be placed on the view menu of the Task View -> New Task and Delete are already on the context menu, so no change is needed. "Restore Default Value" -> Properties view menu -> on the context menu (it applies to the selection), so no change is needed "Back", "Forward", "Up", "Sync w/ Editor", "Collapse All" -> Navigator View menu -> all are in the Navigate menu except for "Collapse All"; collapsing all can be done reasonable quickly using the arrow keys (repeated left arrow collapses the current item) "Delete" & "Go to" -> Bookmarks View menu (doesn't even have a menu yet) -> on the context menu Properties View (3 buttons/2 menu items) <-> Bookmarks View (2 buttons/no menu items). -> this is OK since the other items are on the context menu Under the guideline above both views would have to be adjusted. -> no adjustment is needed
Backed out the change in the PropertySheetPage. Added icon for Go To Resource action. So the recommendation for icons in context menus is to reduce them to a minimum but not necessarily avoid them altogether? I'd like to get the UI Guidelines article updated.
Sent David and Greg a note to update the guidelines.
In the guideline's sentence both *the menu* are misleading if they do not specifically refer to the view pulldown menu -- which is mentioned in the sentences above and one sentence below the citation. The guidelines for the view toolbar should be updated along the lines of Nick's comment #20: "Any action which appears in the toolbar must also appear in a menu--either the context menu for selection based actions, the pulldown menu for presentation actions, or the main menu for other actions--, but there is no need to duplicate every action in the menus within the toolbar." Filed bug 30039 to continue in a different thread because it would be a post 2.1 consideration and doesn't belong to "icons in context menus" :)
Dave and Greg don't own the guidelines any more, we do. Knut, please enter a separate PR against Platform UI with a [UI Guidelines] tag.
Opened bug 30090 to get the guidelines doc fixed.
On the Navigator view: "Filter..." On the Task view: "Filters..."
In build 20030121 the Navigator menu uses "Filters..." The Package Explorer does, too. Also, it's best to open separate bugs for unrelated problems. The PropertySheetPage and TasksList patches ideally would have been in separate bugs as well since they don't address the "icons in context menus" problem. I do appreciate your input!
looked at nightly build 200301230800: Navigator: Filters Tasks: Filter
had it the wrong way round the first time :(
Entered bug 30200 for task view menu.
verified
