Community
Participate
Working Groups
Bug 278102 adds a quick outline for the task editor which conflicts with the WikiText quick outline if a WikiText enabled text field is focused. In all other SDK editors the quick outline is page or editor global rather than specific to controls and the task editor should follow that convention. I suggest to map the WikiText quick outline to Ctrl+Shift+O or to disable it when the task editor context is active.
Created attachment 169845 [details] patch that creates a new context for the source editor, and registers quick outline for the task editor in that context Agreed. Header-based quick outline is probably less useful in the task editor extension. (In reply to comment #0) > In all other SDK editors the quick outline is page or editor global rather than specific to > controls and the task editor should follow that convention. The quick outline command in WikiText is attached to the @contextId="org.eclipse.mylyn.wikitext.ui.editor.markupSourceContext"@. This adheres to convention, what we're doing that's not quite so typical of other Eclipse editors is that we activate this context when the WikiText task editor extension has focus in the task editor. > I suggest to map the WikiText quick outline to Ctrl+Shift+O or to disable it when the task editor > context is active. Disabling makes sense to me. I don't see the need to have it active in the task editor. I've created a patch that causes the WikiText markup editor extension to use a new source context for markup editing. The task editor quick outline command is registered in that new context, making the task editor quick outline come up instead of the markup quick outline. Steffen, can you please review the patch?
Created attachment 169846 [details] mylyn/context/zip
Thanks. This patch looks good to me.
Patch applied.
I still get a popup that prompts me to select the command if I press Ctrl+O in the task editor while a WikiText editing control has focus. I also see two WikiText bindings for Ctrl+O now. David, can you please check what's going on?
I'm not sure how this solution could have possibly worked before, it makes no sense. A key binding conflict is occurring. Key binding conflicts are resolved based on logic in org.eclipse.jface.bindings.BindingManager.resolveConflicts(Collection, Map), which can be summarized as follows: # compare schemes (looking at sheme hierarchy) # compare contexts (looking at context hierarchy) # compare binging types (ie: user or system) We're getting a conflict because: # schemes are the same # contexts have no hierarchy overlap # binding types are always the same (not specified by user preferences) To resolve this issue we'll have to figure out an approach that prevents the keybinding conflict from occurring in the first place, since conflict resolution will fail to choose a preferred keybinding. Let's touch base today.
Created attachment 171124 [details] new patch that creates new context hierarchy There seems to be no way to prevent a keybinding conflict in this case other than to have one of the contexts not register the keybinding. To make this work I've created a new supertype for the markupSourceContext context such that the tasks.ui plugin can extend that context instead of the one used by WikiText source editors. This has the advantage of preserving existing behaviour in WikiText.
Created attachment 171125 [details] mylyn/context/zip
Thanks David. The patch works for me.
Patch applied
