Community
Participate
Working Groups
We seem to have various keybindings issues right now, this is just the umbrella bug to keep track on them.
In Bug 546932 the incorrect assumption of a one-to-one relation between MBindingContext and MBindingTable is removed. This might be related.
(In reply to Rolf Theunissen from comment #1) > In Bug 546932 the incorrect assumption of a one-to-one relation between > MBindingContext and MBindingTable is removed. This might be related. Thanks, that was it.
As far as I know there's no specific trigger that disables the back/forward keybinding. It is in all editors: java, html, text etc.
E3/E4 Keybinding Investigation # TL;DR * The E4 model contributions do not initialize the JFace engine correctly * When the E4 BC's are manipulated through the model, JFace is not notified * When bindings are manipulated through JFace, the runtime model is not notified. * Attaching a top level binding context to an E4 part is ignored when used as plugin # HOW IS KEYBINDING SUPPOSED TO WORK There are Schemes, Contexts, Bindingtables, Keybindings, Commands, and Handlers. We use the extension point mechanism, JFace classes, and the E4 models and model fragments. There is no documentation. Is there anyone who knows how this works? ## Schemes If I understand correctly, Schemes are sets of keybindings for a specific application. In Eclipse IDE we have the default and the emacs Schemes active. The emacs scheme is a child of the default scheme. I am guessing that this is because if some key is not defined in the emacs binding, it falls through in the default binding. Schemes can be investigated by injecting the JFace BindingManager (I don't know how to get it from E3). ## BindingContexts (BC) The JFace Context class is called BindingContext in E4. There is a similar hierarchy as in Schemes. There is a high level BC "Dialogs and Windows" which has two children "Dialogs" and "Windows". As far as I can logically deduce, clients must insert their own BCs under either one of these child contexts and attach the BC to a part or dialog (but they are not forced to). Then if the user presses a key in a part, the key is investigated in the local BC and goes up to the parent chain when not found. This enables clients to retarget a binding to a different command. THIS DOES NOT WORK when an E4 plugin is contributed to E3 or another E4 application. At this moment I am unclear how Schemes and BindingContexts work together. ## BindingTables (BT) The next level is a BindingTable. It groups a number of KeyBindings and there is a one to one attachment to a BC. At this moment I am unclear about why this was designed like this. Maybe it is to be able to redefine a new set of keys when the Scheme changes? # E4->E3 OR E4->E4 Issues The BindingContext model in e4 DOES NOT WORK when used for anything other than a standalone RCP. * It is possible to define a child BC below the "Windows" BC in the model, but this is ignored when the model fragment is merged * Reparenting binding contexts programmatically in the E4 model is possible, however, it has no effect. * Attaching a top-level model BC to a part is ignored when the E4 plugin is contributed to an existing application through a fragment. ## Current solution to fix the E4 binding contexts. The solution to fix the keybindings in an E4/E3 or E4/E4 application: * Define the custom binding contexts as children of the XPATH root context * Add a model addon which: * Iterates over all BCs from the ContextManager to find your BCs * use the define(..) method to reparent under "Dialogs" or "Windows" After this, the E4 keybindings work as expected but the runtime model does not reflect the situation in JFace. Also when BC's are reparented programmatically in the E4 model, JFace is not told about it. ## What needs to be done * The E4 model contributions must initialize the JFace bindings correctly * When the E4 BC's are manipulated through the model, JFace must be notified * When bindings are manipulated through JFace, the runtime model must be notified. * The keybinding beast must be documented.
Created attachment 284629 [details] Difference between jface and runtime model
Created attachment 284630 [details] Snippet on how to reparent E4 in E3 BC's and JFace listing
It has been a while, but I looked into the implementation. To me it seemed that that the current implementation is still half way a migration from E3 to E4. The (old) E3 keymodel [1] is filled from the E4 model on startup. Keybinding preferences/operations are done on the E3 model and then persisted back to the E4 model. The whole implementation seems overly complex and fragile. The E4 model should be single source of truth, therefore, the copy to the E3 keymodel should be eliminated and operations should be done on the E4 model directly. [1] package: org.eclipse.ui.internal.keys.model
(In reply to Rolf Theunissen from comment #7) > It has been a while, but I looked into the implementation. Ok, that is good news. I think first we must reverse engineer the architecture and describe how it is supposed to work on a wiki page. Then we can analyze all the issues based on how it should work. WDYT? > to E4. The (old) E3 keymodel [1] is filled from the E4 model on startup. > Keybinding preferences/operations are done on the E3 model and then > persisted back to the E4 model. The whole implementation seems overly > complex and fragile. Yes. > > The E4 model should be single source of truth, therefore, the copy to the E3 > keymodel should be eliminated and operations should be done on the E4 model > directly. Well, isn't it JFace that takes care of the actual work? This probably must still keep functioning for standalone JFace.
Found bug 286661 that apparently contains an example key state machine
