Community
Participate
Working Groups
I20051102-1600 To allow a fix for bug 64665 (JDT controls with symbol names should be camel-case aware), several keybindings for org.eclipse.ui.edit.text.*word* actions should be moved to the "org.eclipse.ui.contexts.dialogAndWindow" scope (otherwise, they are not available in dialogs. I have a working implementation for bug 64665, which will be released as soon as the keybindings have been moved. I'll attach a patch.
Created attachment 29519 [details] Patch for org.eclipse.ui.workbench.texteditor
Platform Text should not define text widget commands. I see two solutions here: 1) Platform UI adopts the commands (ID must be kept as is) and moves them to the dialogAndWindow context. If so, the content assist commands should be moved as well (they might be useful when resolving bug 106199). 2) in your dialog activate the following two scopes: "org.eclipse.ui.contexts.dialog" "org.eclipse.ui.textEditorScope" Doug, would 2) work? Markus said he tried this but it did not work. Personally I think 1) is the correct solution.
I tried 2) in TextFieldNavigationHandler (in the jdt.ui project): IContextService contextService= (IContextService) PlatformUI.getWorkbench().getAdapter(IContextService.class); contextService.activateContext(IContextService.CONTEXT_ID_DIALOG); contextService.activateContext("org.eclipse.ui.textEditorScope"); This didn't enable the keybinding. However, when I activated context contextService.activateContext(IContextService.CONTEXT_ID_WINDOW); in the dialog, then it suddenly worked. Is this a bug in the context service story? [To use the TextFieldNavigationHandler in e.g. the rename refactoring dialogs, add the line TextFieldNavigationHandler.install(fTextField); to the end of TextInputWizardPage#createTextInputField(..).]
The key binding architecture ignores the text scope because it is a child of the window context. The dialog context is active. You would need to put the binding in the dialogAndWindow context. I am willing to do the following: take camel-case and a bunch of camel-case commands into a new UI plugin, let's say "org.eclipse.ui.camelcase". Then, we can make "org.eclipse.ui.ide" dependent on this. This is roughly outlined in Bug 113096. Also, this would allow us to address Bug 90170. I don't feel that adding it to "org.eclipse.ui.workbench", for example, is a good idea. It would increase the size of all RCP applications, when the functionality is only useful to a subset of RCP applications. Platform/UI does not have any time to commit to this (outside of code reviews).
Word navigation isn't related to camel case and simply because these commands would have to be retargeted for camel case support does not mean they belong to the camel case plug-in / support. >The key binding architecture ignores the text scope because it is a child of >the window context. Mmh, wasn't aware of this and the Javadoc doesn't tell about this either.
Okay, sorry I misunderstood. Then this is just an extension of Bug 43102. Either way, I'd be willing to take these commands and any code to support them into a separate plug-in, and make "org.eclipse.ui.ide" depend on it.
oops, removing the helpwanted keyword.
Just to confirm: is the implementation that makes cut, copy, paste commands work in JFace dialogs done via o.e.u.ide's TextActionHandler? I think a separate plug-in for just those commands would be overkill and in fact they would be hard to implement for the Text widget since word navigation isn't supported through the API, hence adding those commands to the dialog space might be confusion for users since they won't affect most text widgets. What's the reason to block context activation internally? As mentioned before it's not mentioned in the API of activateContext(...) that this might be overridden/ignored. Can you also comment on comment 3, especially why it works when Markus activates the IContextService.CONTEXT_ID_WINDOW context.
(In reply to comment #8) > Just to confirm: is the implementation that makes cut, copy, paste commands > work in JFace dialogs done via o.e.u.ide's TextActionHandler? No, it is done using WidgetMethodHandler. > I think a separate plug-in for just those commands would be overkill and in > fact they would be hard to implement for the Text widget since word > navigation isn't supported through the API, hence adding those commands to > the dialog space might be confusion for users since they won't affect most > text widgets. getSelection, setSelection, getText and setText. I think it would be possible to do most everything using only those methods. > What's the reason to block context activation internally? As mentioned > before it's not mentioned in the API of activateContext(...) that this might > be overridden/ignored. Can you also comment on comment 3, especially why it > works when Markus activates the IContextService.CONTEXT_ID_WINDOW context. Context activation is not blocked, the binding service simply ignores the context. This is done so that -- when a dialog is open -- some key bindings do not unexpectedly work.
>getSelection, setSelection, getText and setText. I think it would be possible >to do most everything using only those methods. I don't think this smoothly works because you don't know what the native behavior does i.e. the user might get different behavior when assigning his own key sequence to "word next" than he'd get when using e.g. Ctrl+Arrow_Right. Unless of course we override the platform key sequences for "word next" with our implementation as well. >This is done so that -- when a dialog is open -- some key bindings >do not unexpectedly work Why does it then work when Markus activates the IContextService.CONTEXT_ID_WINDOW context?
(In reply to comment #10) > I don't think this smoothly works because you don't know what the native > behavior does i.e. the user might get different behavior when assigning his > own key sequence to "word next" than he'd get when using e.g. > Ctrl+Arrow_Right. Unless of course we override the platform key sequences > for "word next" with our implementation as well. I'm not sure what is best here, but we might want to consider overriding native behaviour. As it stands right now, there are several different text behaviours. If I type in a Java editor, Ctrl+Arrow stops on capital letters. In a dialog, however, Ctrl+Arrow stops after spaces. Double-clicking on some text also has different behaviour between a Java editor, a dialog and the plugin.xml text editor. These differences cause me to make mistakes sometimes. > Why does it then work when Markus activates the > IContextService.CONTEXT_ID_WINDOW context? He is overriding the behaviour, and forcing both window and dialog contexts to be active. I could detect (and block) that case, if you'd prefer.
We do not plan to provide those commands in the Platform Text layer.
>We do not plan to provide those commands in the Platform Text layer. Should have added: "for the org.eclipse.ui.contexts.dialogAndWindow scope
This plan still holds but I'm open to move them to Platform UI (org.eclipse.ui) and change it there. This might be a smart move as we could in the future also push down the improved navigation code. Paul, what do you think?
The questions is which set and that's where it becomes ugly ;-) So - probably rather not start to move them.
(In reply to comment #15) > The questions is which set and that's where it becomes ugly ;-) > So - probably rather not start to move them. I have no objections to moving what sound like global navigation commands down to org.eclipse.ui ... but once you are comfortable with the selection of navigation commands that make sense. PW
We should look at this in 3.4, in connection with supporting CamelCase in the Platform (bug 113096 etc.).
