Community
Participate
Working Groups
Currently we have 3 separate keystrokes (Ctrl-F6, Ctrl-F7 and Ctrl-F8) to jump between editors, views and perspectives. Each of those are working well on its own. The good about them is that they allow to maintain historical UI interaction and also allow to use single keystroke for navigation. So, repeated Ctrl-F6 will bring user to any editor from the active list (it cam be also remapped to Ctrl-Tab to make it more convenient for Windows users). Unfortunately that nice interaction breaks when user constantly need to jump between editors and views. You have to remember and be able to reproduce keystroke sequences like Ctrl-F7, ... F12, Ctrl-F6, etc. It is confusing and not very convenient. There is some work in progress that replaces old Ctrl-E dialog with unified navigation, but new Ctrl-E dialog is too overloaded for quick navigation. It also does not provide unified historical ordering between views and editors (actually no historical order even in each category) and does not allow to use single keystroke to skip trough the historical list. I think these issues need to be addressed and Eclipse should provide efficient unified navigation dialog with high usability metrics.
Boris, this isn't strictly editor management but perhaps related to CTRL+E work. PW
We're seeing a trend where editors and views are becoming more similar (although for reasons of existing API they will never be one). I can believe though that we should treat them as one where possible, since the distinction as to whether something became an editor or a view tends to be based more around which real estate you want and do you want edit-save rather then anything particularly deep. This is one example of treating them as one, "places where I have information I care about". I suspect we'd need to keep a distinction though between {views+editors} as one Ctrl action vs. perspectives switching, since that's a different level of navigation (parts vs. container).
(In reply to comment #2) > I suspect we'd need to keep a distinction though between {views+editors} as one > Ctrl action vs. perspectives switching, since that's a different level of > navigation (parts vs. container). I can live with that. Especially if that common navigation history would include views from all perspectives, so I could jump between Paskage Explorer and Debug view and perspective would be switched automatically. That would make user interaction even easier.
With respect to including perspectives in the unified list, it's only my gut that it should be separate, we'd need to experiment. The idea of the list being cross perspective is ... interesting. I don't use these keys so I have no idea if people expect its a list of things they can immediately see, or a list of things they have open somewhere. Making it cross perspective in a sense makes it more useful, because if it only switches things I can see its only marginally better than me just clicking on the tab (which I can see). Often perspectives like the Synchronize one are really there to drive navigation from a specific view (in this case the Synchronize view). If it worked as you suggested, then picking the Sync view when in the Java perspective is a good shortcut for switching perspectives + picking the view (a frequent task). If we think these keys are for power users than I am ok with it being cross perspective, since it requires additional mental work for the user to understand what's going on.
(In reply to comment #4) > The idea of the list being cross perspective is ... interesting. I don't use > these keys so I have no idea if people expect its a list of things they can > immediately see, or a list of things they have open somewhere. The main point that list should be sorted, so even if there are lots of things opened it won't be overwhelming, if the UI would allow single keystroke navigation. At the same time I don't think it is a good idea to have list of all existing views (like Ctrl-E dialog have right now). > Making it cross perspective in a sense makes it more useful, because if it only > switches things I can see its only marginally better than me just clicking on > the tab (which I can see). Often perspectives like the Synchronize one are > really there to drive navigation from a specific view (in this case the > Synchronize view). If it worked as you suggested, then picking the Sync view > when in the Java perspective is a good shortcut for switching perspectives + > picking the view (a frequent task). BTW, I think Synchronize perspective itself is a bad example. Because of that, it is purely adopted. It would be much more natural to have Sync and history view on Java perspective by default. > If we think these keys are for power users than I am ok with it being cross > perspective, since it requires additional mental work for the user to > understand what's going on. Why? How much mental work you need to use Ctrl-Tab, which is basically the same idea of switching between recent things...
>>The main point that list should be sorted, so even if there are lots of things >>opened it won't be overwhelming, if the UI would allow single keystroke >>navigation. At the same time I don't think it is a good idea to have list of >>all existing views (like Ctrl-E dialog have right now). Right, I meant the list would either be things I can see immediately (in this perspective) or things visible in all perspectives. They are part of my "working set" of views. The comment about expert usage is that for some class of users, in particular new or occasional users, they are quite literal in their use of an application. Their mental model of what is going on is based on what they can immediately see. Perspectives are a real challenge for them because as they change perspectives they must assemble in their minds a new mental model. To make use of switching views in different perspectives, it implies that I remember that what's in those perspectives. That's a more advanced user. >>Why? How much mental work you need to use Ctrl-Tab, which is basically the same >>idea of switching between recent things... Switching between views which aren't in the current perspective is different than the Alt-Tab case in that I can see all the windows in front of me, some may be partially obscured, but they are right there and I have tabs for them at the bottom of the screen. My hunch is that the Cntrl-F* functions we're discussing are for power users in which case we're ok with making it cross perspective.
(In reply to comment #6) > Switching between views which aren't in the current perspective is different > than the Alt-Tab case in that I can see all the windows in front of me, some > may be partially obscured, but they are right there and I have tabs for them at > the bottom of the screen. Actually you not always see all the tabs. If there is too many editors or many views in each slot, then they will be folded.
Is there any chance of making Ctrl-Tab a default key binding (as backup?) for Windows users? I'm constantly annoyed I cannot switch views (or more precicely editors) inside the Java perspective as with many other MDI apps?
Andreas, you spoiled it! We should take one step at a time. :-)
(In reply to comment #8) > Is there any chance of making Ctrl-Tab a default key binding (as backup?) [..] On my US keyboard, the ` key is just above Tab, so I've assigned Alt+` to Next Editor and Ctrl+` to Next View and I've been happy with that for years. And I still have Ctrl+Tab for navigation between UI elements.
(In reply to comment #10) Please note that this enhancement request does not suggest to remap keyboard shortcuts, but provide unified way to switch between views and editors. As you indicated again, currently it is not possible to do that using single shortcut and user need to remember which shortcut is used for views and which is for editors.
Remy is now responsible for watching the [EditorMgmt] component area.
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.
