Community
Participate
Working Groups
1. Start Eclipse. Toolbar is visible, right-click gives "Toggle Toolbar Visibility". No cooresponding Window menu item exists. 2. Select "Toggle Toolbar Visibility" Toolbar is now hidden (correct), Window now has item: "Show Toolbar". 3. Select "Show Toolbar" Toolbar is now shown (correct), right-click now gives "Hide Toolbar". 4. Select "Hide Toolbar" Toolbar is now shown (correct), right-click now gives "Hide Toolbar". 5. Exit Eclipse and Restart. Toolbar is now visible again. Suggestions: 1. Preserve toolbar visibility between sessions. (Unless this is a bug in which case it might be causing behavior above.) 2. Starting state should be "Hide Toolbar", not "Toggle.." 3. I think that whenever possible window item changes should be minimal across environment state changes, so Window::Toolbar item should not disappear after a Show Toolbar. Instead.. 3a) Replace with cooresponding "Hide Toolbar" item within Window menu, or 3b) Provide a Checkbox next to "Show Toolbar" that is off when toolbar is hidden.
Correction: 4. Select "Hide Toolbar" Toolbar is now shown.. should be: 4. Select "Hide Toolbar" Toolbar is now hidden (correct), right-click now gives "Shoe Toolbar".
I believe we have a bug for (1) but I can't find it. > Starting state should be "Hide Toolbar", not "Toggle.." Agree, since (1) the inverse is Window->"Show Toolbar" and (2) the menu command isn't a toggle with a checkmark to show state (its inverse is in the Window menu). > I think that whenever possible window item changes should be minimal across > environment state changes, so Window::Toolbar item should not disappear after a > Show Toolbar. Instead.. Its a good point. Actually having "Toggle Toolbar" (or "Hide") in the toolbar itself is a problem since people need to search elsewhere to again make it visible. How are you to guess its in Window? Having "Toggle" or "Hide" in Window would allow a chance to learn that's where it lives permanently. Furthermore, generally context menus are supposed to be shortcuts to existing dropdown menus, so having the menu duplicated in the Window menu as well as context for the toolbar would be a good idea anyway. Note: if we have a "permanent" menu item in Window, then it *could* be "Toggle".
See also Bug 158642
Thanks.. I searched as well, glad I'm not the only one who has a hard time finding already reported bugs. So drop 1, obviously.(In reply to comment #2) > visible. How are you to guess its in Window? Having "Toggle" or "Hide" in > Window would allow a chance to learn that's where it lives permanently. Yes, with key binding, please! > Note: if we have a "permanent" menu item in Window, then it *could* be > "Toggle". I like that idea because it could be a single key-binding. But editorily, I generally don't like "toggle" as its kind of techie. Checkboxes literally *are* toggles. :) btw, I've noticed the same kind of thing where initial state is not reflected in UI in a few places, esp. non platform plugins..Perhaps there is some kind of API issue that makes it difficult to obtain initial workbench state.
I certainly agree that the last known state should be honored on a restart. I also agree that the current Hide (using a TB's context menu) vs Show (using "Window->Show Toolbar") bites and should be replaced; I'd personally lean towards a single command (sited in the 'Windows' menu?) whose label changed from "Hide Toolbar" to "Show Toolbar" as appropriate. This would, as has been pointed out, allow a single key-binding to suffice for toggling. I can't convince myself that "Hide"/"Show" (or 'Toggle' if you'd prefer...;-) is a commonly used operation. Only common operations should have key bindings by default, the available set of bindings is already limited. (you can always tailor one up if you want). Can you make a case for this being a common operation? In fact (I -can't believe- I'm saying this...;-) it may ultimately be best expressed as a 'preference' due to its genrerally static nature. This would also solve the session life-cycle issue.
(In reply to comment #5) > from "Hide Toolbar" to "Show Toolbar" as appropriate. This would, as has been > pointed out, allow a single key-binding to suffice for toggling. Agreed. > I can't convince myself that "Hide"/"Show" (or 'Toggle' if you'd prefer...;-) > is a commonly used operation. Only common operations should have key bindings fair enough..I'm usually just trying to hide the thing, but think laptop/limited real estate. > In fact (I -can't believe- I'm saying this...;-) it may ultimately be best > expressed as a 'preference' due to its genrerally static nature. This would > also solve the session life-cycle issue. Actually, isn't it really a Perspective thing? e.g. is Perspectives simply stored toolbar state along with frame positions.. For example, I've been laying around with having a different perspective for when my laptop is hooked up to a monitor and when it isn't (no outline view, etc..) and I would want the toolbar off by default for that perspective.
I really like your use-case of having two different 'modes' that you'd like to run in based on the screen res... I'm not sure that Perspective's are the way to go however. Even in your workflow you'd likely want to have -every- perspective either show/hide the TB based on whether you're docked or not (just in time for Hallow'een...Eeeek!!...resolution-based preferences, scarey...;-).
I would like to add my support for getting this resolved. The fixes mentioned by Eric are all good. My preference would be for remembering the state on close and making the menu option Hide Toolbar/Show Toolbar. A preference would not be useful, since it is not really a static choice.
Bumping. I just want to see if we could get this into 3.5.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
