Bugzilla – Full Text Bug Listing
| Summary: | No binding table for org.eclipse.ui.contexts.dialog | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | UI | Assignee: | Brian de Alwis <bsd> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bsd, codingkriggs, daniel_megert, dennis.huebner, emoffatt, gary, pwebster, remy.suen, sebastian.zarnekow |
| Version: | 4.2 | ||
| Target Milestone: | 4.2.1 | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Markus Keller
Replicated for me as well. Version: 4.2.0 Build id: I20111209-2100 Here's the stack trace of the System.err.println (using conditional breakpoint with "Thread.dumpStack(); return true;" on the offending line): java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1273) at org.eclipse.e4.ui.bindings.internal.BindingServiceImpl.deactivateBinding(BindingServiceImpl.java:111) at org.eclipse.e4.ui.workbench.renderers.swt.cocoa.CocoaUIHandler.addCloseDialogBinding(CocoaUIHandler.java:367) at org.eclipse.e4.ui.workbench.renderers.swt.cocoa.CocoaUIHandler.access$3(CocoaUIHandler.java:360) at org.eclipse.e4.ui.workbench.renderers.swt.cocoa.CocoaUIHandler$1.run(CocoaUIHandler.java:225) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4620) at org.eclipse.e4.ui.workbench.renderers.swt.cocoa.CocoaUIHandler.init(CocoaUIHandler.java:214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) at org.eclipse.e4.core.internal.di.InjectorImpl.processAnnotated(InjectorImpl.java:838) at org.eclipse.e4.core.internal.di.InjectorImpl.inject(InjectorImpl.java:110) at org.eclipse.e4.core.internal.di.InjectorImpl.internalMake(InjectorImpl.java:317) at org.eclipse.e4.core.internal.di.InjectorImpl.make(InjectorImpl.java:252) at org.eclipse.e4.core.contexts.ContextInjectionFactory.make(ContextInjectionFactory.java:177) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.createFromBundle(ReflectionContributionFactory.java:93) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.doCreate(ReflectionContributionFactory.java:64) at org.eclipse.e4.ui.internal.workbench.ReflectionContributionFactory.create(ReflectionContributionFactory.java:49) at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:252) at org.eclipse.ui.internal.Workbench$3.run(Workbench.java:534) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:520) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at com.example.Application.start(Application.java:20) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:352) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:624) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:579) at org.eclipse.equinox.launcher.Main.run(Main.java:1433) at org.eclipse.equinox.launcher.Main.main(Main.java:1409) Still in 4.2 M7. (In reply to comment #2) > Still in 4.2 M7. Still in 4.2 RC1. Causes a Key Binding conflicts for our org.eclipse.ui.contexts.dialogAndWindow bindings. Brian, any idea what the problem is? Is the Cocoa handler running before the binding system has been fully activated? PW (In reply to comment #4) > Brian, any idea what the problem is? Is the Cocoa handler running before the > binding system has been fully activated? I don't actually know . The intention is to bind a close-dialog command for Cmd-W in CocoaUIHandler (an add-on). CocoaUIHandler.java: private void addCloseDialogBinding() { TriggerSequence sequence = bindingService .createSequence(CLOSE_DIALOG_KEYSEQUENCE); ParameterizedCommand cmd = commandService.createCommand( COMMAND_ID_CLOSE_DIALOG, null); Binding binding = bindingService.createBinding(sequence, cmd, EBindingService.DIALOG_CONTEXT_ID, null); bindingService.deactivateBinding(binding); <--- triggering the message bindingService.activateBinding(binding); } But looking at the code in BindingServiceImpl, the actual message is just a diagnostic: BindingServiceImpl.java: public void deactivateBinding(Binding binding) { String contextId = binding.getContextId(); BindingTable table = manager.getTable(contextId); if (table == null) { System.err.println("No binding table for " + contextId); //$NON-NLS-1$ return; } table.removeBinding(binding); } activateBinding() simply returns if the table is not available and the binding is dropped. So if we see the message, then the deactivate/activate should actually be a no-op. public void activateBinding(Binding binding) { String contextId = binding.getContextId(); BindingTable table = manager.getTable(contextId); if (table == null) { return; } table.addBinding(binding); } And in fact, Cmd-W doesn't work in the few dialogs I've just tried. So I don't think this attempt to perform the binding is actually doing anything. Paul: what is the best way to install a binding? I have some code in the CSS Spy that laboriously looks for and creates a table; it's kind of a pain. Dennis: given that the binding isn't actually installed, I don't think this is the source of your key binding conflicts. What are you seeing? (In reply to comment #5) > Dennis: given that the binding isn't actually installed, I don't think this is > the source of your key binding conflicts. What are you seeing? Brain, unfortunately I can't reproduce it anymore. But, the warning were logged for our key bindings that are in our own scope: <context name="%context.editingText.name" description="%context.editingText.description" id="org.eclipse.xtext.ui.embeddedTextEditorScope" parentId="org.eclipse.ui.contexts.dialogAndWindow"> </context> Conflicting binding were (e.g. for org.eclipse.ui.edit.text.goto.wordNext), between our and org.eclipse.ui.contexts.window context. Although warnings were logged, our bindings worked as expected. Just got it again here is one of logged warnings, they are all similar only the key differs: A conflict occurred for COMMAND+SHIFT+ARROW_RIGHT: Binding(COMMAND+SHIFT+ARROW_RIGHT, ParameterizedCommand(Command(org.eclipse.ui.edit.text.select.lineEnd,Select Line End, Select to the end of the line of text, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), org.eclipse.ui.internal.MakeHandlersGo@5be69f12, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.ui.textEditorScope,,cocoa,system) Binding(COMMAND+SHIFT+ARROW_RIGHT, ParameterizedCommand(Command(org.eclipse.ui.edit.text.select.lineEnd,Select Line End, Select to the end of the line of text, Category(org.eclipse.ui.category.textEditor,Text Editing,Text Editing Commands,true), org.eclipse.ui.internal.MakeHandlersGo@5be69f12, ,,true),null), org.eclipse.ui.defaultAcceleratorConfiguration, org.eclipse.xtext.ui.embeddedTextEditorScope,,cocoa,system) Eclipse SDK Version: 4.2.0 Build id: I20120524-2100 It's not really related to this bug as it is in different scopes. (In reply to comment #7) > Binding(COMMAND+SHIFT+ARROW_RIGHT, > ParameterizedCommand(Command(org.eclipse.ui.edit.text.select.lineEnd,Select > org.eclipse.ui.textEditorScope,,cocoa,system) > Binding(COMMAND+SHIFT+ARROW_RIGHT, > ParameterizedCommand(Command(org.eclipse.ui.edit.text.select.lineEnd,Select > org.eclipse.xtext.ui.embeddedTextEditorScope,,cocoa,system) Because org.eclipse.xtext.ui.embeddedTextEditorScope is not a child of org.eclipse.ui.textEditorScope and both contexts are active, you have a real keybinding conflict. If you want to track it down, please open another bug. In 3.x in this situation neither of the keybindings would work. In 4.x it will continue to pick up the org.eclipse.ui.textEditorScope keybindings. The tables are sorted based on the # of levels of parents their context has. textEditorScope is at least a 3, the xtext scope is a 2. PW Hi Paul,
I don't see how both contexts can be active.
We code which looks pretty much like this:
protected void initialize() {
final IContextService contextService = (IContextService) workbench.getAdapter(IContextService.class);
/* viewer is a SourceViewer on a preference page */
Shell shell = viewer.getTextWidget().getShell();
final ActiveShellExpression expression = new ActiveShellExpression(shell);
final IContextActivation contextActivation = contextService.activateContext(EMBEDDED_TEXT_EDITOR_SCOPE, expression);
shell.addDisposeListener(new DisposeListener() {
public void widgetDisposed(DisposeEvent e) {
contextService.deactivateContext(contextActivation);
}
});
..
}
and the bindings are registered in the plugin xml like this:
<key
commandId="org.eclipse.ui.edit.text.select.lineEnd"
platform="carbon"
sequence="M1+M2+ARROW_RIGHT"
contextId="org.eclipse.xtext.ui.embeddedTextEditorScope"
schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"/>
How could the default text editor scope be active in that context?
I'm not sure that I follow all the discussion about binding conflicts, but it seems to me that no matter what the cause is, bundles should not be writing directly to syserr (or sysout). (In reply to comment #10) > I'm not sure that I follow all the discussion about binding conflicts, but it > seems to me that no matter what the cause is, bundles should not be writing > directly to syserr (or sysout). I agree, that should be logged or moved into DEBUG mode. PW Fixed in master (e8654a1fc4c9dc50cd2eea6803cffa672dd5c304). Commented out the error, fixed the keybinding installation to create the binding table as required. Verified in M20120829-1200. |