Community
Participate
Working Groups
Once inside the Terminal view, it is hard to get out of it using keyboard only since all keyboard commands are designed to go to the remote, not the IDE. This is by design for the terminal view for now. For example, I could not use Ctrl-F7 to switch to a different view in the workbench.
What key commands do you think should work? Is there any standard for accessibility that would dictate this? We need detailed requirements in order to make any changes.
Try Ctrl+Tab. That is the key sequence needed to traverse out of a multi-line text control in the forward direction. Ctrl+Shift+Tab traverses out of a multi-line text control in the reverse direction. Does this work for your Terminal view?
Created attachment 227813 [details] potential fix to use ctrl+tab to get out of terminal view This patch adds a traverse listener to check for CTRL+TAB. It ignores other tab events given terminals are likely to want to consume them.
Dave D, any thoughts on this approach?
I'm not very comfortable with a hard-coded Ctrl+Tab interception right in the terminal widget. This breaks the assumption that everything is sent to the remote - and is not even intuitive, I'm not aware of any other view that would use Ctrl+Tab (am I missing something?) Here are a couple ideas for a better solution that I would accept: 1. Use the standard CUA key (press + release the ALT key) which opens the main menu to get out of the Terminal. This would probably be the least intrusive solution. 2. Make the "terminal exit key(s)" configurable. There is a number of keys which are usually used in Eclipse for switching views (just see the Window > Navigate menu). People who don't care about sending these to the remote should be allowed using _all of them_ in the editor. See also bug 241098 . Some typical keys that would be interesting to be re-assignable: F10 (toggle main menu) Ctrl+F10 (toggle context menu) Ctrl+[Shift]+F6 (cycle editors) Ctrl+[Shift]+F7 (cycle views) Ctrl+[Shift]+PgUp/Dn Alt+Space (Window / System menu) 3. Make any accessibility change only in the "RSE Terminals" view but not in the core terminal widget. 4. Has any interaction between terminal and IME (for entering multi-byte characters in Chinese, Korean etc) ever been looked at ? Now this all looks a bit complex for what you're trying to accomplish, but essentially my one acceptance criterion is very simple: Make it possible (through Preferences, settings or however) that users of the Terminal widget can still send _all_ keys to the remote. And, don't regress in that functionality by default compared to previous versions of the Terminal widget.
Created attachment 227835 [details] potential fix isolated to RSE view This version of the patch just applies to the RSE view. I really don't know what the optimal key combo(s) are here so I'm just going on what Carolyn mentioned with the Ctrl+tab.
Hi, Martin. In SWT, both Tab and Ctrl+Tab move focus to the next control in the tab order. (Shift+Tab and Ctrl+Shift+Tab move focus in the reverse direction). Since multi-line Text controls typically consume the Tab key (so the user can type a Tab into the text), and since we needed a way to traverse out of a multi-line Text control, Ctrl+[Shift]+Tab was chosen as an alternate traversal method. This decision was made a long time ago, in the very early days of SWT. Question for you: Is the VT100TerminalControl code at this link fairly current? http://code.google.com/p/elt/source/browse/com.google.eclipse.tm.terminal/src/org/eclipse/tm/internal/terminal/emulator/VT100TerminalControl.java?r=832b6b7af54bf31414bfbb8c612b76b72b38eccd If so, and if I am reading the code correctly, then it looks like Ctrl+Tab is never sent to the remote - it is just sent as plain Tab? Same with the Eclipse Window -> Navigation accelerators that you mentioned in point 2 of comment 5. For example, I think Ctrl+F6 is being sent to the remote as just F6. If I am wrong, then I apologize, but if this is the way the VT100TerminalControl is really working, then it's possible that none of your users have ever needed Ctrl+Tab or Ctrl+F6, and they wouldn't care if they were used for their common Eclipse purpose. I think Ctrl+[Shift]+F6, Ctrl+[Shift]+F7, Ctrl+[Shift]+F8 and Ctrl+[Shift]+Tab are all available to use. So David's RSE view fix in comment 6 looks fine to me. (I assume it works? <g>) It would also be nice if RSE could enable the Window -> Navigation accelerators. This would need new API in the terminal widget, because it disables Eclipse key bindings when it gets focus. I guess this is what you meant by "configurable" in comment 5 point 2. So the terminal widget would check the set of RSE-supplied "terminal exit key(s)" and if there's a match, it would call forceCommandExecution(KeyEvent e). Note that F10 and Alt+Space are provided by the OS, so they should just work. Ctrl+F10 is a very common key binding for the context menu, so you probably don't want to use it for anything else, and Ctrl+[Shift]+PgUp/Dn is hard-coded in SWT's traversal mechanism for switching pages in a TabFolder or CTabFolder. Does press + release ALT key currently work (give focus to the main menu bar) from the terminal view?
(In reply to comment #7) Hi Carolyn, > Question for you: Is the VT100TerminalControl code at this link fairly > current? > http://code.google.com/p/elt/source/browse/com.google.eclipse.tm.terminal/ > src/org/eclipse/tm/internal/terminal/emulator/VT100TerminalControl. > java?r=832b6b7af54bf31414bfbb8c612b76b72b38eccd No, this looks like a fork of our code which was forked off perhaps a year ago. I didn't take the time investigating what modifications Google has made and why, and specifically why they haven't taken the time getting in touch with us, filing bugzilla items and getting their modifications back into mainline. The most current version of our code is here: https://git.eclipse.org/c/tm/org.eclipse.tm.git/tree/terminal/plugins/org.eclipse.tm.terminal/src/org/eclipse/tm/internal/terminal/emulator/VT100TerminalControl.java > If so, and if I am reading the code correctly, then it looks like Ctrl+Tab > is never sent to the remote - it is just sent as plain Tab? There is an easy way testing what gets sent: Just create a folder named C:\eclipselogs then operate the terminal, and it will log your interactions. Use /tmp/eclipselogs to accomplish the same on Linux. Doing that, I can confirm that it looks like Ctrl+[Shift]+Tab are indeed sent as a plain tab (ASCII 9) as of today. You may also be right that modifier + F5/F6 are not correctly sent today, but I do not think this is an excuse for stealing keys in an incorrect way. For all the keys on a keyboard, including the function keys, multiple different encodings exist (PuTTY and others allow some selection there), but the xterm assignment ESC[n~ is perhaps most widely used. See also http://microvga.com/ansi-codes Here is an example of where a user deliberately wanted F1 and F10 to be sent to the remote side through the terminal, rather than eaten by the local system: http://askubuntu.com/questions/37313/how-do-i-deactivate-f1-and-f10-keybindings-in-gnome-terminal > It would also be nice if RSE could enable the Window -> Navigation > accelerators. This would need new API in the terminal widget, because it > disables Eclipse key bindings when it gets focus. I guess this is what you > meant by "configurable" in comment 5 point 2. Correct, it would make sense to make it configurable what keys are sent to the remote vs what keys are interpreted by the IDE. > Note that F10 and Alt+Space are provided by the OS, so they should just > work. Ctrl+F10 is a very common key binding for the context menu, so you > probably don't want to use it for anything else. Again, it must be possible to send _all_ keys to the remote, and F10 for instance is being sent to the remote as expected today. Running "emacs" or "mc" on a remote Linux terminal is a very good test case for completeness of the Terminal's key command handling. > Does press + release ALT key currently work (give focus to > the main menu bar) from the terminal view? Unfortunately this doesn't work today, but I'd like to see that work (since it's just a change in modifiers which can never be sent to the remote, so stealing that one in a hardcoded way is acceptable).
(In reply to comment #6) > potential fix isolated to RSE view If that fix isolated to RSE does in fact work, it would be acceptable for me. Have you tested that fix against an unchanged terminal widget ? Getting an additional fix for the press-and-release-ALT handling would be very good IMO, and getting keyboard interception configurable would be ideal.
Created attachment 227888 [details] Screenshot of Target Explorer In TCF Target Explorer, the Ctrl+PgUp / Ctrl+PgDn keys are used to switch tabs, but they don't help getting out of the Terminal View. The Ctrl+Tab, F10, Ctrl+F10, Alt press+release, Ctrl+F5/F6/F7/F8 keys all do _not_ work in TCF Target Explorer today, so having those keys configurable (send to remote or the IDE) would be beneficial for TCF Target Explorer as well.
Xuan, could you please review my second patch?
The fix looks good. Thanks.
Thanks for the review, Xuan. I've committed the change.
