Ctrl-Tab to switch between files [imported] #195
Comments
ffissore
added
Component: IDE user interface
|
CTRL-TAB is working with the latest build, but not CTRL-SHIFT-TAB to go back on the previous tab. |
|
It would be useful if CTRL-TAB switched between the files you last used, and not EVERY file. I want to be able to quickly jump between two files, not step through all files in the project. |
Previously, the keybinding for Ctrl-Tab didn't check the status of the Shift key, so it would also trigger when pressing Ctrl-Shift-Tab. This resulted in switching tabs forward *and* back, making it look like the switch back was not working. Closes: arduino#195
Previously, the keybinding for Ctrl-Tab didn't check the status of the Shift key, so it would also trigger when pressing Ctrl-Shift-Tab. This resulted in switching tabs forward *and* back, making it look like the switch back was not working. Closes: arduino#195
Previously, EditorListener handled these keys, by registering a handler in the text area. This meant that they would only work while the text area was focused. By registering the keys as WHEN_IN_FOCUSED_WINDOW bindings, they can always be handled, and EditorHeader seems like a more appropriate place. Note that this does not currently work (so this commit breaks these keys), since these keys are also handled in a few different places as well, preventing these newly added keybindings to take effect. This will be fixed in the next commit. One additional change is that previously, these keybindings did not work when the text area was readonly. This was probably a remnant from when EditorListener took care of a lot of other editing keybindings, but this does not make much sense anymore now. Finally, with the old bindings, ctrl-shift-tab did not (seem to) work. What happened is that the binding for ctrl-tab did not check the shift state, so both bindings would fire on ctrl-shift-tab, switching forward and back again, making it seem the keys did not work. The Swing keybinding mechanism that is now used for these bindings checks the complete keystroke, including all modifier keys, so this problem is fixed by this change. References arduino#195
In the previous commit, these bindings were moved to EditorTab and registered in a cleaner way, but this move also allows more components to hijack these keystrokes and prevent them from reaching EditorTab. This commit makes the keybindings work again, by preventing other components from handling the keys. In particular: - JSplitPane had a binding to switch between its two panes, which is now removed after creating the JSplitPane. - The default focus traversal manager in Swing uses these keys to traverse focus (in addition to the the normal tab and shift-tab keys). By removing these keys from the set of "focus traversal keys" defined for the window, this should be prevented when the focus is on any component inside the window. - JTextPane didn't respond to the previous modification of the window-default focus traversal keys, since it defines its own set (to only contain ctrl-tab and ctrl-shift-tab, but not tab and shift-tab, for undocumented reasons). To fix this, focus traversal is simply disabled on the JTextPane, since this wasn't really being used anyway. There was some code in SketchTextArea that tried to modify the focus traversal keys for just the text area, which is now removed. This code wasn't really useful, since focus traversal is disabled for the text area already. Also, the code contained a bug where it would not actually set the new set of keys for the backward focus traversal. Closes arduino#195
Previously, EditorListener handled these keys, by registering a handler in the text area. This meant that they would only work while the text area was focused. By registering the keys as WHEN_IN_FOCUSED_WINDOW bindings, they can always be handled, and EditorHeader seems like a more appropriate place. Note that this does not currently work (so this commit breaks these keys), since these keys are also handled in a few different places as well, preventing these newly added keybindings to take effect. This will be fixed in the next commit. One additional change is that previously, these keybindings did not work when the text area was readonly. This was probably a remnant from when EditorListener took care of a lot of other editing keybindings, but this does not make much sense anymore now. Finally, with the old bindings, ctrl-shift-tab did not (seem to) work. What happened is that the binding for ctrl-tab did not check the shift state, so both bindings would fire on ctrl-shift-tab, switching forward and back again, making it seem the keys did not work. The Swing keybinding mechanism that is now used for these bindings checks the complete keystroke, including all modifier keys, so this problem is fixed by this change. References arduino#195
|
I missed some of the details of this proposal:
|
|
@lmihalkovic, I think those are two separate feature requeste, perhaps you should file them as such? |
|
@matthijskooijman yes, they are distinct features. The first one was part of the original posting (AFAIK it is still not fully implemented), and the second seems to have been added @Scalpel78 more recently (added new entry for it #4350). My intention I was just to direct attention to the fact that the main entry is closed but these smaller details seemed to have fallen through the cracks. IMHO the first one is a great UX improvement for which you might want to consider reopening this item and finish including it in your recent rework (doing it in my fork). |
|
thinking about it further.. it might even be nice for users to support
|
|
@lmihalkovic thanks for opening the new issue. Regarding the "switch on release" thing, I suspect you mean that you will switch when "ctrl" is released, instead of when tab is released? I do not think that the currently used java keybindings mechanism easily supports something like that, so we'd have to switch to processing key events directly. Also, I'm not sure what the advantages of adding this are. If you just switch the tab bar, or perhaps show a tab list popup, why not just switch tabs right away? Anyway, if you feel that this is an important feature, could you also create a new report for it. Even if it was originally part of this request (which I'm not so sure), it will keep discussion cleaner if there is a separate issue for it. |
My reading of the second line is that as long as the keys are held, no switching is done. which is very convenient if someone has a sketch with a handful of tabs. This is also the way the app switching works on OSX (don't remember how it is on windoze). Just tested: Xcode jumps immadiately between tabs before releasing keys (sluggish feel when you jump 2 tabs away from the current). Safari also jumps immediately but at least it is not sluggish... will still try to the app-switcher way (jump only on release and press ESC to cancel switching away from current tab). btw: as for the sub-grouping, Xcode has a fixed size list of "recently edited" files in a submenu, and no visible (so far) shortcut to cycle through only them. Yes, you're correct that CTRL releasing is what dictates when the jump happens. not sure you are correct about the how though (have to test something before I speak stupidly). |
the first piece seems to be there... will check the rest later I will when I see that there is a simple way through. |
Previously, EditorListener handled these keys, by registering a handler in the text area. This meant that they would only work while the text area was focused. By registering the keys as WHEN_IN_FOCUSED_WINDOW bindings, they can always be handled, and EditorHeader seems like a more appropriate place. Note that this does not currently work (so this commit breaks these keys), since these keys are also handled in a few different places as well, preventing these newly added keybindings to take effect. This will be fixed in the next commit. One additional change is that previously, these keybindings did not work when the text area was readonly. This was probably a remnant from when EditorListener took care of a lot of other editing keybindings, but this does not make much sense anymore now. Finally, with the old bindings, ctrl-shift-tab did not (seem to) work. What happened is that the binding for ctrl-tab did not check the shift state, so both bindings would fire on ctrl-shift-tab, switching forward and back again, making it seem the keys did not work. The Swing keybinding mechanism that is now used for these bindings checks the complete keystroke, including all modifier keys, so this problem is fixed by this change. References arduino#195
In the previous commit, these bindings were moved to EditorTab and registered in a cleaner way, but this move also allows more components to hijack these keystrokes and prevent them from reaching EditorTab. This commit makes the keybindings work again, by preventing other components from handling the keys. In particular: - JSplitPane had a binding to switch between its two panes, which is now removed after creating the JSplitPane. - The default focus traversal manager in Swing uses these keys to traverse focus (in addition to the the normal tab and shift-tab keys). By removing these keys from the set of "focus traversal keys" defined for the window, this should be prevented when the focus is on any component inside the window. - JTextPane didn't respond to the previous modification of the window-default focus traversal keys, since it defines its own set (to only contain ctrl-tab and ctrl-shift-tab, but not tab and shift-tab, for undocumented reasons). To fix this, focus traversal is simply disabled on the JTextPane, since this wasn't really being used anyway. There was some code in SketchTextArea that tried to modify the focus traversal keys for just the text area, which is now removed. This code wasn't really useful, since focus traversal is disabled for the text area already. Also, the code contained a bug where it would not actually set the new set of keys for the backward focus traversal. Closes arduino#195
|
turns out it displaying a summary of the file (like the ALT-Tab app switcher) and only jumping when the right file is selected works fine and is somehow convenient: it means one can cycle through the list of files quickly to find the desired file without being delayed by the inertia of actually switching tab. you may want to look into it more closely. |
|
example design for switching only when releasing ATL, and showing target file name in the meantime (working code though)
|
This is Issue 195 moved from a Google Code project.
Added by 2010-01-30T13:46:10.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.
Original labels: Type-Enhancement, Priority-Medium
Original description
What change would like to see?
Pressing Ctrl-Tab advances to the next tab.
Pressing Ctrl-Shift-Tab switches to the previous tab.
Why?
The Ctrl-Tab behavior is so often implemented in applications that I, and
possibly many other developers, are very used to this.
Some applications allow you to just navigate through the tabs in a defined
order (like Firefox, Chrome and Internet Explorer).
Some even remember the order of tabs you've accessed and allow you to
switch between them in the accesses order (like Visual Studio, TextPad,
UltraEdit). Like Alt-Tab does in Windows, and probably on other OSes too.
Would this cause any incompatibilities with previous versions? If so, how
can these be mitigated?
The only 'incompatibility' I can come up with is that people will not be
able to insert tabs while pressing Ctrl anymore. Though I think it's
unlikely anyone would do that.
An example of method 1:
An exmaple of method 2:
Library.h
The text was updated successfully, but these errors were encountered: