Community
Participate
Working Groups
It would be nice to be able to modify keystrokes to effect individual types of windows (such as the package explorer, the task manager, etc) without changing the current window focus. A use case: Precondition: editor open to some file, the package explorer visible, the window focus is currently on the editor 1. The user hits the keystroke to move the package editor focus up. 2. The package editor focus moves up. If an editor is not associated with the current package editor item, the editor does not change. 3. The user resumes typing. Keystrokes are automatically directed to the editor that is currently open. Postcondition: The window focus remains the same. The position of the cursor within the editor remains the same (assuming that the user has not selected a file open in a new editor). The selected item in the package explorer has changed. The package editor is, of course, used only as an example.
Can you restate your use case? What is a "package editor"?
Oops -- sorry, meant "package explorer", but you can substitute any "View" into its place. I shall explain the rationale behind the idea. I'm used to using an environment where keystrokes provide a lot of control (the linux "ide": multiple desktops, vim, make, and gdb). I avoid using a mouse for health reasons. Having to use a mouse to click onto various hotspots inside of an IDE feels slow, inaccurate, and somewhat unpleasant - even worse, clicking on these hotspots is a modal action: it causes the editor to lose focus, so I have to use the mouse to get back to what I was previously doing. This makes the environment slow and tedious to use. My proposed solution is a set of keybindings that would modify the content of Views without changing the current focus. For example, it seems as if the "Package Explorer" is the primary way of navigating the the package hierarchy and changing which file is currently visible in the editor - it would be nice if there was a keybinding mechanism that would change the current selection in the Package Explorer without changing the current input focus. For example - if I want to change the currently selected package member, it would be nice if I could bind some keys (such as "Ctrl-Up" and "Ctrl-Down") to change the current selection in the Package Explorer. It would be logical if it were possible to bind any key combination to go to some (currently visible?) view. Does that answer your question?
You can navigate around the workbench without the use of a mouse. For example, if you press F12, it will give focus to the currently visible editor. You can use Ctrl+F6 and Ctrl+Shift+F6 to cycle thru the open editors (like you can using Alt+Tab in MS Windows to cycle thru open windows). You can use Ctrl+F7 and Ctrl+Shift+F7 in the same manner to cycle thru views. See Window > Keyboard Shortcuts sub-menu. You can also use Ctrl+Shift+T or Ctrl+Shift+H to open an editor on a Java class/interface. Your suggestion has merit but I see several problem trying to make this a general workbench mechanism the user could understand and use. For example, given the user has more than one view open and visible at a time, how would the workbench know which view the shortcut key is for? It seems this feature could be accomplished if the workbench provided macro support and these macros could be bind to a shortcut key. So you could create a macro that would give focus to the Package view, move the selection down one, and give the focus back to the visible editor. Then assign a shortcut key to it. Support for macros is an item being considered for the 3.0 plan.
