Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1. open 2 files in editor 2. try to switch tabs using CTRL + TAB 3. More information: I mean that CTRL + TAB is "standard" shortcut - try firefox, opera, netbeans etc.
Hmmm... Cntrl-tab gives us accessibility so we can move between control groups, one of which is actually the editor tabs (another is the toolbar). Once highlighted, you can move back and forth between the tabs using arrow keys. I agree that consistency with web browsers is valuable, just commenting that we're currently using cntrl-tab for something larger. Tod any thoughts?
Ctrl-Tab is the standard up level tabbing in most OS's. If we break how tabs work to be consistent with a different paradigm (web browsers) we will be breaking OS behaviour which we try hard to avoid. If the platforms we run on switch to this behaviour so should we.
*** Bug 210311 has been marked as a duplicate of this bug. ***
Tod, put yourself in a User point of view. I'm NOT ABLE to set the shortcut in Eclipse to cycle through tabs using CTRL Tab and CTRL SHIFT TAb. Eclipse should AT LEAST offer the possibility to set it up. Users don't care about OS Paradigm. We just want to be able to reproduce the feature that exists in browsers because it is EFFICIENT. You should provide a solution even if it's not built in. This is a MAJOR flaw of the IDE. Visual Studio offers it built-in and users LOVE it because it's efficient.
Something we should consider in er/4.1 PW
Would be nice to have this along with bug 325422.
(In reply to comment #6) > Would be nice to have this along with bug 325422. This is a problem on two levels. First Ctrl+Tab cycles between tab groups in Swing and is a common metaphor for switching to the next tab in all of the main browsers. I don't see any obvious way around this! However the key problem (pun intended) is that there are several ways to navigate between editors and the most common requirement of simply Next Editor/Previous Editor which DO have keyboard shortcuts of Ctrl+PgDown and Ctrl+PgUp respectively are not listed in the Keys preferences (or at least I could not find it). So when people search for the key combo to switch editors in Keys prefs they only find the option to show a popup list of editors and choose which to switch to which is Ctrl+F6. Surely the solution would be to add Next Editor/Previous Editor to the Keys prefs with Ctrl+PgDown and Ctrl+PgUp and then rename the other option to say Switch Editor which more accurately describes its function.
Can any developer fix this please? The main problem is the cycle through tabs: It should go to the next tab (the tab on the right) or the previous (the tab on the left), like in Firefox,Chrome,etc.. and what it really does is just prompt a tab list and by default it points to the last tab you visualized. For example, if we have these tabs: [A][B][C][D] And I press the Next Editor shortcut, eclipse should go to tab [B], and if I press it again go to [C].. if then I press the Previous Editor shortcut, it should go to [B], etc... Many thanks, this bug makes me crazy and will save me lots of time in development if it gets fixed.
(In reply to comment #8) > Can any developer fix this please? This is being worked on in 4.1 PW
Actually the control tab should work as in Netbeans - switch to the *most recently used Tab*, ie keep a stack of tabs and pop the previously visited tab. Cycling through tabs is quite inadequate - as one usually selects one tab with the mouse then wants to jump back to the previous tab - or back and forth - quickly via control tab. For people who want to cycle through tabs (for reasons unknown, but time will tell) there should be the option to do so (as in Notepad++ IIRC). Those being said I am quite amazed that eclipse does not support control tab in the editor - it is incredible really
Bottom line is that this worked in 3.7 and still works in 3.8, but not in 4.x. There are other built-in shortcuts (e.g. "Toggle Breakpoint" , which I want to reassign to F9) that the Keys preferences dialog will allow you to reassign, but when you come to use them the functionality does not work as expected (the toggle breakpoint pops up a tooltip select list to select either "Rebuild Last Target" or "Toggle Breakpoint"). This behaviour is surprising, disappointing and a change from the existing previous behaviour.
I concur with Palmer Eldritch on the point that the desired behavior of Ctrl+TAB is "cycle through tabs in the most-recent-first order." All other things equal, and even disregarding the well-established paradigms, I believe this is optimal for productivity, although I know of no user studies to back up the claim.
I still think this should be the default as most IDEs, text editors, terminals, browsers and other software have the ctrl-tab/ctrl-shift-tab behavior to switch between next/previous tabs by default. I know it's not a reliable source, but ihateeclipse.com has a very high rage score on this feature not being the default behaviour...
The behaviour is already in place. - use CTRL+PageUp and CTRL+PageDown to switch between tabs (non circular) - and use ALT+PageUp and ALT+PageDown to switch between sub tabs So, the question now: can we agree on changing KeyBingdings ?
(In reply to Patrik Suzzi from comment #14) > The behaviour is already in place. > > - use CTRL+PageUp and CTRL+PageDown to switch between tabs (non circular) > - and use ALT+PageUp and ALT+PageDown to switch between sub tabs > > So, the question now: can we agree on changing KeyBingdings ? Is CTRL+Tab currently used in the Eclipse IDE?
(In reply to Lars Vogel from comment #15) > (In reply to Patrik Suzzi from comment #14) > > The behaviour is already in place. > > > > - use CTRL+PageUp and CTRL+PageDown to switch between tabs (non circular) > > - and use ALT+PageUp and ALT+PageDown to switch between sub tabs > > > > So, the question now: can we agree on changing KeyBingdings ? > > Is CTRL+Tab currently used in the Eclipse IDE? Currently not used AND I have mapped it to "Next Editor" command AND it works since years flawlessly on Win/Lin in the same way as it does in Opera/Firefox/you name it. So personally I would just replace Ctl+F6 with Ctrl+Tab binding but I guess Mac is as usually special with this shortcuts.
(In reply to Andrey Loskutov from comment #16) > (In reply to Lars Vogel from comment #15) > > (In reply to Patrik Suzzi from comment #14) > > > The behaviour is already in place. > > > > > > - use CTRL+PageUp and CTRL+PageDown to switch between tabs (non circular) > > > - and use ALT+PageUp and ALT+PageDown to switch between sub tabs > > > > > > So, the question now: can we agree on changing KeyBingdings ? > > > > Is CTRL+Tab currently used in the Eclipse IDE? > > Currently not used AND I have mapped it to "Next Editor" command AND it > works since years flawlessly on Win/Lin in the same way as it does in > Opera/Firefox/you name it. > > So personally I would just replace Ctl+F6 with Ctrl+Tab binding but I guess > Mac is as usually special with this shortcuts. Brian, can you comment for Mac?
To test the behavior, open from menu: Windows > Preferences > Keys Then search "Next Tab" and "Previous Tab", and assign the CTRL+TAB and CTRL+SHIFT+TAB bindings (When: In dialogs and Windows). With Neon under Win10 work fine, until Eclipse restart (<-a conflict?). The related commands ids are org.eclipse.ui.navigate.nextTab and org.eclipse.ui.navigate.previousTab, as you can see in org.eclipse.ui/plugin.xml Note: I was not able to set CTRL+Tab as Key binding in org.eclipse.ui/plugin.xml > Extensions tab, under the bindings node. Actually, I can not find the "Tab" binding anywhere.
Control-Tab seems to have some special meaning on OS X with accessibility. It cycles between controls in most application. But on Safari it does switch between tabs. Using Patrik's configuration in comment 18 for Next Tab and Previous Tab works fine.
I can proceed by editing /org.eclipse.ui.ide/plugin.xml and linking: - org.eclipse.ui.navigate.nextTab to M1+TAB - org.eclipse.ui.navigate.previousTab to M1+M2+TAB The only strange thing is I don't see any declared shortcut using TAB. Is there some special reason for that?
(In reply to Patrik Suzzi from comment #20) > The only strange thing is I don't see any declared shortcut using TAB. > Is there some special reason for that? Assuming you mean no explicit bindings for plain TAB: Tab, Shift-Tab, and Alt-Tab are handled by the WS/OS.
New Gerrit change created: https://git.eclipse.org/r/71207
The proposed solution works for Win(10) and Linux(Ubuntu). Brian, could you please tell if this is ok also for Mac ? Thanks and Regards.
Gerrit change https://git.eclipse.org/r/71207 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4fad790e2c3d17d57e5315a9a55ece077e845b39
Fixed for 4.6M7.
New Gerrit change created: https://git.eclipse.org/r/71248
Gerrit change https://git.eclipse.org/r/71248 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=55a63d1e4ff2df2d80a99c400330e617a9a5888e
This broke accessibility, at least on Windows and GTK. In SWT, Ctrl(+Shift)+Tab is used to put the focus to the next/previous control when Tab already has another function (e.g. in an editable text field). A prime example is a textual compare editor in which both sides are editable.
Maybe this is something we incorporate into the Oomph Welcome Questionnaire.
(In reply to Markus Keller from comment #28) > This broke accessibility, at least on Windows and GTK. Thanks for the feedback, and for fixing this. > In SWT, Ctrl(+Shift)+Tab is used to put the focus to the next/previous > control when Tab already has another function (e.g. in an editable text > field). A prime example is a textual compare editor in which both sides are > editable. I see your point, and think we can use special context in Editable Texts where: - Ctrl(+Shift)+Tab put focus on next (prev) control (as it is now) - pressing Esc, the focus is back to the Composite Container, so Ctrl(+Shift)+Tab works for switching tabs. In that case, we could have both "good parts", with the only hassle that the user have to remember to use ESC to exit from the "editable text contexts". Do you think this could work?
(In reply to Patrik Suzzi from comment #30) > Do you think this could work? No. As said before, Ctrl+Tab is a general accessibility feature that needs to work without any client-specific hacks. Out of the box, Eclipse will stay accessible. Allowing users to rebind Ctrl+Tab would be fine, and showing default bindings like Ctrl+Tab and Ctrl+PageDown in the Keys preference page would also be nice, but only if you can guarantee that the addition of these bindings doesn't influence anything unless the user sets the bindings to non-default values. E.g. a solution where the key binding infrastructure catches a traverse event and then re-posts the event would already be unacceptable, since that could break existing display filters.
Keeping this open as we should evaluate adding this to the Oomph Welcome Questionnaire. See comment #29
If we're interested in Using Ctrl+Tab, I think we could: - keep the defaults as they are to preserve accessibility. - add a preference for using Ctrl+Tab, but warn the user that breaks accessibility . - add a question in the Oomph welcome questionnaire to set that preference.
I just tried to assign Ctrl+Tab / Ctrl+Shift+Tab to the Next Tab/Previous Tab action in the keys preference page and it works. So it's definitely doable. Now, I see as major issue that the existing Ctrl+Tab action and Ctrl_PageUp/Ctrl+PageDown don't show up in keys and are basically impossible for a regular user to discover.
I think there is a dependency on bug 535503 to at least allow user to manage existing shortcuts.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
