Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Accelerator rework? (workbench eats Control+Z)



This is covered by one of the "top ten" issues for 2.1.
http://www.eclipse.org/eclipse/development/challenges_2_1.html
Work on this is about to be set up.
Kai


Which one?  I just see something about changing key-bindings.  Does that include not consuming key-bindings?



See RH>




Are any 2.1 plans underway to solve the accelerator problem.  The problem
is that a Control cannot receive a keystroke if it is registered somewhere
in the Menu.  A related problem is that a child Control has focus, and you
would like certain keystroked to get promoted to a parent or ancestor (like
PAGE_UP in the PDE's plugin.xml editor).

SA> Do you want all keystrokes not consumed by the child to be past on up
to the parent? Or do you only want to allow some keys and if so, how did
you envision to tell the control this?


RH> I was just pointing out a related problem.  I *think* AWT handles this by passing all key events up the parent chain.  I know there are a lot of problem with AWT, but I haven't heard "keystroke propagation" mentioned.

For those unfamiliar with the problem, the Workbench registers Actions with
Control+Z and other accelerators.  As a result, Native controls will not
receive undo  keystrokes, etc.  The workaround required by UI developers
who have an editor filled with Text controls in cumbersome.  You must
register an action for Undo with the workbench.  That action must enable
and disable as a result of each change on every text control in the editor,
and it must follow focus, and it must forward the undo action to the
control.  If anyone extends your Editor and adds a new page to it, you'd
better plan for a UndoRedoCutCopyPasteHelper as well, if you want those
functions on that page.

SA> The accelerator key assigned to the Undo action is dependent on the
accelerator configuration you have active. If it is the default one, then
its Ctrl+Z, if its emacs, then its another shortcut key as Ctrl+Z is used
in emacs to scroll one line. Now if the text control got the key
beforehand, your emacs keybinding would not work properly.


RH> I assume you are talking about styledtext and similar widgets.  In this case, AbstractTextEditor would have to add a keyListener to the StyledText widget.  KeyListeners would be notified before default behavior occured (in this case Undo), and AbstractTextEditor would "consume" Control+Z so that the widget doesn't perform undo (maybe it would just consume every key event).  I think SWT should have (or has) a way to override default key handling other than registering a menu accelerator.  Doing this on one control is easier that the alternative of doing it on every Control where you just want the platform keys to work.

SA> I do agree with you that the workaround provided by the workbench is
poor (having the developer figure out they need to hookup this undo action.
One area we are looking at is to make this much more easier for the plugin
developer. If you have suggestions for this, please let us know.

SA> It is an area that we are looking at improving for 2.1 if possible.

In addition to Undo/Redo/Cut/Copy/Paste, there are tons of other problems
that result from the current keyboard handling.  For example, accessibility
is broken whenever the Java Editor is up.  I cannot use Control+SPACE to
toggle selection in any tree, table, or other control in the workbench.

SA> If you could list what all the problems are that the current keyboard
handling is causing you, we can then look at solving them. If you could
also open a problem report for each one of these, that would be helpful for
us to track these issues. For the one about control+space, please open a
problem report with steps on how to reproduce it

RH> It is impossible to enumerate all scenarios on an open platform, but I've logged that specific one already.  Given EditorPart E, and View V, accelerators registered by E will steal keystrokes from V.  E and V might be from unrelated plugins from different plugin providers.

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev


Back to the top