Community
Participate
Working Groups
3.3 M3 - right click on a view tab - Close is at the bottom, after the system menu entries - I'm far more likely to want to choose Close on a tab (e.g. on an inactive tab that doesn't have the close box) than the system actions Likewise, in the editor tabs, Close, Close All, New Editor are probably more common choices than the system actions. I it would be better to move the system actions to the bottom.
Firefox puts Close at the bottom of the tab context menu, IE7 at the top. I guess the argument for having close at the bottom is that it is consistent with Window's window menu (on the window title bar, and entries in the task bar). Not sure which would work better, all I can say is that Close should either be the first or the last menu item so that its position can be predicted with certainty. Kevin? (A mildly related question is why Ctrl-F4 closes the active editor even if the focus is in a view - should it not close the current part regardless of whether it's a view or an editor? I'm sure this has been discussed before...)
A close part command was added in bug 77014 but none of hte keybindings were changed ... the user can update themselve. PW
re Ctrl+F4, it closes the editor rather than the active part because otherwise the use would need to be more aware of what part they're in when they want to close the editor. I use Ctrl+W all the time, and I don't have to care about which part I'm in. Views tend to be pretty stable compared to editors. A shortcut for closing the current part is Alt+-, C. For menu item placement, placement at the top, the bottom, or adjacent to a separator are easiest to access. The most frequently used items should go at the top.
(In reply to comment #1) We should probably move Close and New Editor to the top. I could rationalize the Firefox decision based on the fact that there is an clear, obvious affordance for closing (the little close box) so use of the Close menu item is secondary. Meanwhile, opening of a new editor is a frequent task, so it makes sense to have it top of the menu, and there is no correponding immediate affordance (other than accelerator). The Eclipse editor menu has stack operations (Minimize/Restore/Move) and these are pretty clearly more infrequent than Close/Close Others/Close All. For that reason, moving the Close entries up could be arguably good. Mind you the menu is small enough that I could see people arguing that we should not confuse existing users by moving them. I'd suggest also we move New Editor to the top because with the new tab management its going to be a more likely operation than the others. Frankly, I'd rather see the resource's operations in that menu than these useless Move/Size/etc, but that's a different problem :)
I concur that operations on the editor input would be better to have on the tab menu rather than cluttering the context menu (I suggested this to Doug a while back, but he didn't like the idea).
Remy is now responsible for watching the [ViewMgmt] category.
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.
