Community
Participate
Working Groups
The following are suggestions for polish items concerning menus owned by Platform UI. Window Menu remove Hide Editors Lock Toolbars (not the popup) change Preferences... TO Preferences Navigate WITH PROBLEMS VIEW SELECTED rename Next TO Next Problem Previous TO Previous Problem <The following is a proposal for back + forward etc...> ADD Navigate > "View" > Go Into / Back / Forward / up one level / and Possibly Go To Line... Navigate > Editors > Back / Forward / Previous Member / Next Member /Matching Bracket REMOVE Go To menu and all remaining sub items File Move "Open External File..." and "Open Workspace..." to their own group below Print. Rename "Open Workspace..." TO "Switch Workspace..." Remove separator between Refresh and Rename
Note: Navigate > Go To > Type... package... and Resource... should be in the views menu as well, however they are global re-targetable actions, so editors 'could' hook them.. .but putting them in the view menu would set a better precident.
*** Bug 35360 has been marked as a duplicate of this bug. ***
A question regarding Window menu change. Why drop the ... from Preferences? This makes the preference action inconsistant with every other action that launches a dialog (Customize Perspective, Save Perspective As, etc).
To clarify: the Problems view does not provide action handlers for next and previous, so there is no way to override these strings. Grouping Open Workspace/Open External File below Print will either require a) a new API constant in IWorkbenchActionConstants or b) overloading IWorkbenchActionConstants.OPEN_EXT to also be applicable to the file menu. What would you prefer?
You are correct neither the problems, tasks, nor bookmark view register global action handlers for Next and Previous. This is inconsistent with the other views (search, synchronize, junit). I therefore suggest that these views also register global action handlers for next and previous with custom labels Next Problem, Next Task, Next Bookmark.
we can't add API right now, I prefer option 2 in comment #4, and we re-visit later.
It's fine to reuse OPEN_EXT in other contexts.
Re comment #3, "..." is only used when the action needs further input to complete the action. Here, the action is to open the perspectives dialog, so it doesn't need further input. Help > About is the same. The GUI Bloopers book discusses this. It's also mentioned here: http://msdn.microsoft.com/library/en-us/dnwue/html/ch08b.asp "(Ellipses are typically used when further input from the user is required to carry out the command.)"
Kim, can you clarify what has been done for this bug?
Nothing has been committed as of yet. The following is done and waiting for committal: hide editors and lock toolbars removed. open workspace/external file to their own group and open workspace renamed seperator between refresh and rename is gone
This wont make it in for RC1. Deferring to RC2.
Nick, re comment 8: as of 3.0 M9 'Window > Preferences...' has the trailing ellipsis. Is it a bug then? (no, if you ask me - it opens a dialog and whenever i see a menu entry with no ellipsis i'm soft of expecting that (possibly unwanted) things will happen and i should be careful. here, there's nothing to be careful about. maybe the bloopers book had a blooper then :)) Also, Microsoft's IE has 'Tools > Internet Options...' with the ellipsis. I don't feel strongly about either option though.
IE's Options... item doesn't follow their own guidelines. I guess it depends on whether you interpret the Preferences[...] action as being "Open preferences dialog" or "View preferences" vs. "Change preferences". If it's the latter, then the ellipsis makes sense, since the operation is not complete until the dialog is brought up, the user makes their change, then presses Apply or OK.
*** Bug 65217 has been marked as a duplicate of this bug. ***
Re: Comment #13 Nice to see that we're thinking UI polish. I have noticed a distinct drop in consistency of the Eclipse UI in this release compared to those in the past. Yeah yeah, they're all nits but hey... if you buy a Mercedes, the doors shouldn't squeak, the cupholders should be straight, and the floormats should fit. :-) To the point, my understanding of "ellipsis or not" is pretty simplistic: Q1. Is there another dialog displayed? If yes, then... Q2. Is the dialog that's displayed the "destination" or an attempt to further clarify a pathway to the "destination"? The "Save As..." choice is real clear on this point since the subsequent dialog is just clarifying what I would have liked to say up front, if there were such a means (contrast with "Save"). The "Properties" choice is less clear but still fits within "Dan's destination rules," albeit not quite as obviously as "Save As...". Specifically to an earlier point, in my view, the "Preferences" page is the same as the "Properties" choice. So no ellipsis. Re: Comment #12 I see your point, but the problem with the simplified rule "if a window or dialog shows up, it needs an ellipsis" is problematic. Lots of menu choices have confirmation dialogs ("Are you sure?") and worse yet, these can be turned on and off. That means, for example, "Delete" in one case and "Delete..." in another. What quickly results is a near systematic application of the ellipsis to menu choices except for the most trivial of cases (e.g., Copy [to clipboard]). If the majority of the menu choices end with "...", the meaning is lost. The menu I've attached it typical of an appropriate application of the MS style guide / Dan's rule. Six of the choices present **some** window, but only three have "..." -- that's because they have to ask the question, "which one of XXX are you talking about?" The remaining three don't and thus are destinations in and of themselves. I hope this rambling was helpful. If so, then maybe all those years in CUA- land didn't go completely to waste (if you don't know what CUA stands for, don't ask and consider yourself lucky ;-).
Created attachment 11467 [details] Typical menu with and without ellipsis
Created attachment 11504 [details] Patch for org.eclipse.ui.editors Partial fix
Created attachment 11506 [details] Patch for org.eclipse.ui.workbench Partial fix
Created attachment 11507 [details] Patch for org.eclipse.ui.ide Partial fix
The patches look fine to me.
The above patches have been applied. I am still investigating the reorganization to the Navigate menu
Created attachment 11722 [details] Possible change Without indroducing new workbench constants for an editor menu (and reusing the goTo constant to mean "Views") this is what we can do. I don't think this is much of an improvement at all. I'd sooner defer this to 3.X where we can define new constants for both views and editors and deprecate "Go To".
Created attachment 11727 [details] Patch for org.eclipse.ui.ide Patch for the above refactoring
Created attachment 11728 [details] Patch for org.eclipse.jdt.ui
Agree, so we will not add new API at this stage and will defer the re-work of the Views vs Editor navigation items till post 3.0. It is also unclear whether we should reuse Go To for views as others might contribute non-view items here. Moving to 3.1 for the two remaining items, updating the title to represent what is left.
Spotted another period for a checkbox. Funny how these crept into 3.0 (third case?), I don't recall ever seeing such an example in 2.x. See attached.
Created attachment 11902 [details] GUI blooper
Thanks for spotting that - Bug 66574.
Not for 3.1? This has been in my bucket for ages. I just found it... what should I do about this?
It's probably been made obsolete by the 3.1 menu review. Should verify with MvM.
this is no longer valid, a new review of menus should be made on 3.2
