Community
Participate
Working Groups
A windows control is scrolled (without changing focus item or selected item) by invoking CTRL+SHIFT+UP/DOWN. Eclipse is currently using CTRL+UP/DOWN, however this is reserved for changing focus item without changing selection. GEF is using the accessibility convention of CTRL+ARROW, and therefore cannot use the default eclipse keybinding for scroll up/down. If eclipse would switch, we could reuse the keybinding.
Moving to Platform Text, as I believe they own these commands.
Platform text defines Scroll Up/Down which is bound to Ctrl+ArrowUp/Down in the "Editing Text" context. I cannot find a global up/down command. Can you give more details. What do you mean by Ctrl+ARROW (up, down, left, right)?
Scroll Up/Down is not restricted to text editing contexts. It applies to Trees, Tables, and graphical applications. So move it up to the default context. There is no global action, but there are the keybindings, which could have "global" context. I think that's "in windows and dialogs" or something like that. The keybindings (and optionally actions in text editor) for Scroll Left/Right are missing.
It's not Text components business to declare this action in global scope.
"org.eclipse.ui.edit.text.scroll.lineDown" and "org.eclipse.ui.edit.text.scroll.lineUp" are both declared in "org.eclipse.ui.workbench.texteditor". I don't feel it is a good idea to declare key bindings in "org.eclipse.ui" for plug-in's that are dependent on "org.eclipse.ui". Nice try though. :)
Doug, Randy is asking for general scroll up/down. We define scroll line up/down >I don't feel it is a good idea to declare key bindings in "org.eclipse.ui" for >plug-in's that are dependent on "org.eclipse.ui". Not sure what you mean here. Doesn't it already define lots of commands?
Randy seems to be wanting the key binding in text editor, but moved to a higher context. This is still possible from your plug-in. Right now, you guys define those commands, so unless you want to move them to workbench or ide, there's not much we can do. I don't feel that duplicating the command is a great idea.
scrolling a line might be possible in Trees and Tables but not in graphical applications as asked for.
I don't believe he's asking that you implement the functionality, only that the command's key binding be made available in a more general context. It would then be possible for others to provide their own handlers for their own types of editors and views. But I'm just guessing at this point. Perhaps Randy will have more info when he comes into work today.
We are not scrolling a line. Just some small percentage of the client area. So I guess we wouldn't be able to use the command unless its translated label were generic such as "scroll down". If this isn't possible that's fine. However, there is an existing convention which is being ignored.
It is not currently possible to allow handlers to override the text of a command. It is possible to add this support. The original intention was to add this support; I'm not sure why it wasn't added before Chris left. If you would like Platform UI to provide that support, please open an enhancement request.
So to clarify even more <g>, the original issue is: 1) Windows uses CTRL+SHIFT+DOWN to invoke "line down". Eclipse doesn't. The secondary issue is: 2) Can the workbench relabel and promote such actions to be generic in context. >when he comes into work today. My first comment was at 10:00 AM today :-P
re 1) What do you mean by "Windows"? E.g. Word or Notepad which definitely are Windows apps do not behave as you outlined.
windows == win32: such as Tree, Table, List, Text(SWT.MULTI). Not sure why microsoft only supports this keybindings sometimes and not other places. Anyway, using CTRL+SHIFT+UP would be consistent with the few existing native controls. Using CTRL+UP to navigate methods would be consistent with using CTRL+UP in word processors to navigate "paragraphs", and also is somewhat consistent with CTRL+RIGHT, and CTRL+PAGEUP.
Randy can you file a request for enhancement for (2). Assign it to me, and preface it with "[Commands]". It will likely not be looked at for 3.0, but it is something I'd like to provide in the 3.1 time frame.
>windows == win32 I knew ;-) Please give me some concrete Win X *text editing* apps that behave as outlined above. I tried all my daily apps and none behaves as you describe. re 2: Once 2 is in place in Platform UI, Text can retarget that command for up/down and drop his own.
I really don't know any windows text controls which allow CTRL+SHIFT+UP==SCROLL UP. Nor any cases where CTRL+UP==SCROLL UP.
Setting to remind. Will reconsider once global scroll action is in-place.
Get rid of deprecated state.
.
