Bug 567265

Summary:	E3 key bindings (from o.e.ui.workbench.prefs) conflict with E4 key bindings from workbench.xmi
Product:	[Eclipse Project] Platform	Reporter:	Erdal Karaca <erdal.karaca.de>
Component:	UI	Assignee:	Platform-UI-Inbox <Platform-UI-Inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	rolf.theunissen, wim.jongman
Version:	4.18
Target Milestone:	---
Hardware:	PC
OS:	Windows 10
Whiteboard:
Bug Depends on:
Bug Blocks:	552208

Description Erdal Karaca

2020-09-23 01:30:01 EDT

In a RCP app when user modifies key bindings (within same key binding context)  such that the new binding conflicts with an existing binding, the changes will be written to bot E3 workbench prefs AND E4 workbench.xmi state file.

On next start of application only the keys from the workbench.xmi will be properly handled. Existing key bindings from E4 workbench prefs will be loaded anyways and lead to conflicts again.

As a hack: before the E4 app is started, delete the o.e.ui.workbench.prefs file at file system level (assuming only key bindings persisted in that file).

Comment 1 Erdal Karaca

2020-09-23 01:32:36 EDT

I think the key bindings should not be written to both E3 and E4 state files in:

org.eclipse.ui.internal.keys.BindingService.savePreferences(Scheme, Binding[])

Comment 2 Erdal Karaca

2020-09-23 01:36:39 EDT

Additionally, the user has to unbind the other conflicting binding which internally will be tagged as "deleted" in E4 workbench xmi.

(In reply to Erdal Karaca from comment #0)
> In a RCP app when user modifies key bindings (within same key binding
> context)  such that the new binding conflicts with an existing binding, the
> changes will be written to bot E3 workbench prefs AND E4 workbench.xmi state
> file.
> 
> On next start of application only the keys from the workbench.xmi will be
> properly handled. Existing key bindings from E4 workbench prefs will be
> loaded anyways and lead to conflicts again.
> 
> As a hack: before the E4 app is started, delete the o.e.ui.workbench.prefs
> file at file system level (assuming only key bindings persisted in that
> file).

Comment 3 Erdal Karaca

2020-09-24 02:37:37 EDT

It seems the root cause is not the duplicated E3/E4 storage of key bindings. But after all fragments have been applied (ModelAssembler), some system key bindings may have been restored and conflict with user defined key bindings.

Now, I have another addon which deactivates system key bindings which conflict with user key bindings. Still, this seems like a hack.

Comment 4 Wim Jongman

2020-11-01 14:18:16 EST

(In reply to Erdal Karaca from comment #3)
> It seems the root cause is not the duplicated E3/E4 storage of key bindings.
> But after all fragments have been applied (ModelAssembler), some system key
> bindings may have been restored and conflict with user defined key bindings.

Keybindings should depend on the context. I think you should not add top keybindings to the e4 application that overrides the e3. For example, F1=Help. 

> 
> Now, I have another addon which deactivates system key bindings which
> conflict with user key bindings. Still, this seems like a hack.

E4 should follow the E3 keybinding scheme. E3 cannot be altered but E4 can piggyback.

So the trick should be to parent your keybindings below the "dialogs" or "windows" which root parent is "dialogs and windows".

"dialogs and windows" F1=Help
  "windows" 
    "your_part_context" F1=Something else

If the user is outside your view, F1 will trigger help. Inside your view F1 will do something else.

Now the trick is, how to parent the E4 contexts below the main contexts? I have found no way to do it in the model, although it should be straightforward by importing the binding context you want to parent under. However, this does not work.