Community
Participate
Working Groups
Ctrl is not normally used for keybindings on Mac. Command is used instead.
For consistency with other actions, this should be fixed in 3.0, and is low risk.
CC Kai for RC3 approval
Ant does not define the keybindings for formatting. We currently just re-use the binding declared for the Java editing by setting the action definition id to be IJavaEditorActionDefinitionIds.FORMAT.
Moving to JUI for consideration
From looking at the plugin.xml this seems to be OK (at least for Java formatting). André can you verify on the MAC whether this works for Java formatting and Ant editor? If done please move back to JDT Text it is not working in Java editor and to Platform Ant if it's only not working in the Ant editor. Thanks.
ping.
In Java editor "Format" is bound to Shift-Command-F, in Ant editor it is bound to Control-Shift-F
See also bug 112533
Investigate for 3.2
Should just work with bug 112533
Please ensure you have keyboard happiness on the Mac.
No happiness in mac land :-( format is still mapped to ctrl-shift-f.
Created attachment 33297 [details] screen shot I'll look into this ASAP.
The JUI action is defined in the "Editing Java Souce" context. That context is not active when an ant editor is the active editor. Ctrl-Shift-F works, but doesn't seem to be bound to a command(???). WorkbenchKeyboard doesn't get notified when the key combination in pressed and they keybindings preference page doesn't indicate that anything is bound to that key combination.
"org.eclipse.ant.ui" defines its own Format command (why is that anyway?).
Ant UI no longer defines its own format command (removed via bug 112533). Kevin has found our problem (we are explictly setting the shortcut in a property file) and we will continue to investigate.
The format action in the ant editor is an old ResourceAction. Doug is there a standard way of converting these actions to the new commands story? It's constructed in AntEditor.createActions() if you want to look at the code.
Created attachment 33494 [details] patch Followed the same pattern used by JUI. Removed the accelerator from the properties file. Set the action definition id to be IJavaEditorActionDefinitionIds.FORMAT created keybindings in ant.ui's plugin.xml to add the ant editor context.
Dani: I believe we have to consider creating a "org.eclipse.ui.editing" context. We could then move key bindings that are sufficiently common into it. This avoids Ant re-defining the Format key bindings, and avoids GEF re-defining the next/previous word bindings.
Sounds like a great idea. I'm sure SSE's XML editor is probably borrowing commands from JDT, yet they aren't editing java (well, except for JSPs... and javascript).
There are two different problems here: 1) the stuff that GEF wants, like navigation commands, is currently defined in Platform Text using the org.eclipse.ui.textEditorScope which is (for historic reasons) defined in org.eclipse.ui. This problem of moving the commands those covered in bug 123838. 2) source commands which are currently defined in JDT UI and which also have their own context defined in JDT UI. To solve this we had planned to provide an LTK UI plug-in but this is currently on hold. Having said that, the problem with moving the contexts and commands is that we currently don't have a migration story i.e. if we move the stuff to Platform UI we must keep the same IDs at least for the commands while for the contexts we could probably solve this by extending the new context.
Dani: Keeping the ids the same does not seem like a big barrier to me.
If Platform UI accepts IDs with ".text." and ".java." in org.eclipse.ui and Platform Text is still considered to be the owner of that stuff then I'd be willing to do this, but we have to be aware of the fact that we not only propagate the "java" and "text" IDs to Platform UI but also see them ripple into CDT, GEF, etc. Nick, what do you think about this?
I think that's the best we can do for 3.2. IDE-oriented commands, scopes and bindings should go in org.eclise.ui.ide though, not org.eclipse.ui, so as not to (further) clutter the command and binding space for RCP apps.
OK, but then I'd probably revive the LTK UI plug-in for the source commands which is already in the repository.
OK. Please coordinate with Doug as to which commands should go in org.eclipse.ui.ide vs. org.eclipse.ltk.ui.
Doug, an initial set of source commands can be seen by checking out org.eclipse.ltk.ui from the repo. The text (navigation) commands would have to be put into org.eclipse.ui and not org.eclipse.ui.ide since org.eclipse.ui.workbench.texteditor does not depend on ui.ide and is considered an optional RCP plug-in.
GEF does not depend on IDE or LTK, so how are we going to pick up PreviousWord, etc.?
If commands had contexts associated with them, and, if a context could be defined as abstract, then those commands would not clutter RCP apps unless a concrete context existed in the app. So, for example, PreviousWord would be defined in some abstract context. The texteditor plug-in, or GEF, would extend that context, making the commands defined in it "real", and they would then appear in the keybindings preference page.
Randy, that was exactly my point in comment 27: they would have to be put into org.eclipse.ui.
Dani: The format provided does not have the same ID as the existing format command. Was this intentional? Kevin: Can you guys depend on org.eclipse.ltk.ui and use the format command defined there? Randy: If you want some text commands moved to org.eclipse.ui, can you please open a separate bug and provide a patch?
OK, but, are commands like "next word" going in an optional plug-in, or can they go in UI? Is the optional plug-in the "language toolkit"? I'm not sure that actions like end-of-line only apply to programming languages. What do you think of the idea of an abstract context? One that doesn't appear in the preferences until a concrete extending context is found. Of course, it doesn't get you much unless a new attempt is made at filing commands in their anticipated contexts.
>Dani: The format provided does not have the same ID as the existing format >command. Was this intentional? No. The current state of o.e.ltk.ui was made under the assumption that we'd get a migration layer, I guess you remember that discussion. I would have to change them to match those in JDT UI and remove them from JDT UI. Dani: The format provided does not have the same ID as the existing format command. Was this intentional? >Kevin: Can you guys depend on org.eclipse.ltk.ui and use the format command >defined there? Some more details since Kevin might not know about LTK UI: this layer would contain code which is useful to those implementing some toolkit/IDE for a programming language. It is not yet in the build but in the repository. >Randy: If you want some text commands moved to org.eclipse.ui, can you please >open a separate bug and provide a patch? The bug is already there, it's bug 123838. Randy, please provide a patch that removes the commands and key binding definitions from Platform Text and adds them to Platform UI. Doug and I will then review the patch and if we both accept it I can do the move since I have commit rights on both projects. OK?
Regarding comment 32: the navigation stuff better fits o.e.ui thant o.e.ltk.ui.
I believe we could depend on LTK UI...when will it be included in the build?
I'd prefer to do this for M6 since we have lots of API stuff for M5, but if it's urgent for you and Randy then we'll try for M5.
It is not urgent for Ant...this bug exists in 3.1 and can wait for 3.2 M6
Dani, Is moving ltk.ui into the build for M6 still a possibility?
See comment 33: we are still waiting for the patch.
applied patch (attachment 33494 [details]) to HEAD to enable Format for M6. Moving to Randy since comment #33 and comment #39 imply a patch is forthcoming.
I'm not a platform committer, so assigning it to me won't help. Besides, comment 33 was talking about a patch for a different issue, no?
Marking fixed then. Adding dependancy on bug 123838. We can reexamine this fix when that bug gets resolved.
Darin, please verify
Marking verified.
