Community
Participate
Working Groups
Support for doit=false in KeyEvents will likely be dropped (Bug 367871) and replaced with CANCEL_KEYS (Bug 367869). We should adjust our JFace code accordingly.
I started the evaluation of JFace/Workbench usage of KeyEvent doit = false. I will put some notes (document the classes involved) before the real re-factoring take place: - KeySequenceText#KeyTrapListener#handleEvent cancel all key events after handle them manually. The key handling logic is very complicated there. As this class is *not* in use by JFace/Workbench code we could keep this code untouched. - KeySequenceText#TraversalFilter#handleEvent - cancel TRAVERSE_RETURN and all TRAVERSE_TAB_NEXT/TRAVERSE_TAB_PREVIOUS with modifier different than SHIFT. - ContentProposalAdapter#TargetControlListener - cancel ESC, CR and TAB. The code that cancels other keys is currently commented. - ContentProposalAdapter#addControlListener - cancel triggerKeyStroke defined by the user. As we have plans to completely rework the ContentProposalAdapter functionality (see bug 330461) we could defer it.
- ColumnViewerEditor#processTraverseEvent - cancel TRAVERSE_TAB_PREVIOUS and TRAVERSE_TAB_NEXT - ComboBoxCellEditor#createControl - cancel TRAVERSE_ESCAPE and TRAVERSE_RETURN - ComboBoxViewerCellEditor#createControl - cancel TRAVERSE_ESCAPE and TRAVERSE_RETURN - TextCellEditor#createControl - cancel TRAVERSE_ESCAPE and TRAVERSE_RETURN - SWTFocusCellManager#handleKeyDown - cancel keys defined in CellNavigationStrategy#shouldCancelEvent (default are ARROW_LEFT and ARROW_RIGHT, but can be changed with a custom navigation strategy)
- FilteredPreferenceDialog#activeKeyScrolling - cancel everything with display filter if "Key Scrolling" action is activated. - WorkbenchKeyboard#processKeyEvent - cancel all *consumed* key binding events. The logic to cancel or not the event is in WorkbenchKeyboard#press and it's very complicated. Currently we cancel all defined key binding events (BindingManager#updateKeyBindingList).
Forms: - ExpandableComposite - cancel ARROW_UP and ARROW_DOWN - FormText - cancel TRAVERSE_TAB_NEXT and TRAVERSE_TAB_PREVIOUS in a condition.
Currently, I can see two potential problems: 1. Possibility to cancel *all* key events on a specific control. 2. Cancel a key event in a condition.
1. So how about a whitelist as a solution? Or allow a wildcard in CANCEL_KEYS? 2. Is this critical? Could we solve it with a piece of client-side code?
JFace code has been adopted to use CANCEL_KEYS instead of doit = false in key/traverse listeners. The following classes stay unchanged: KeySequenceText FilteredPreferenceDialog WorkbenchKeyboard FormText Changes are in CVS HEAD.
I will close it as fixed. JFace code has been adapted, where possible.
