Re: [platform-ui-dev] What is being done in 3.0 to clean up accelerator

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

> In 2.1 and AFAIK right through M6, an editor
writer (me) has a heck of a 
> time trying to get through the accelerator key briar patch. Specifically,
> 
> - The org.eclipse.ui.editorActions way of specifying accelerator keys
> seems to have been orphaned (without being deprecated). Keys assigned
in 
> that way just don't work if there is any conflict with another key
> assignment, and when they do work don't participate in the user dialogs
> for reassigning, enabling, etc. accelerator keys.

The 'org.eclipse.ui.editorActions' way of specifying
accelerator keys is the
"accelerator" attribute. This attribute
has been deprecated in the schema
since Jan 23 2003.

If you still use this older method, in an event of
a conflict with the new 
command system, you will lose your accelerator.


> - It seems to be impossible for an editor to remap an accelerator
key 
> defined by another plug-in, like the Navigate > Open Declaration
(F3) 
> mapping done by Java. You can receive the action, but nothing I have
> found will make the accelerator key work outside of Java.

First, the key binding for Navigate -> Open Declaration
is defined by JDT 
in the general context. I'm not sure where you can
use 'Open Declaration' 
outside of the Java Editor, so you might want to raise
this issue with them,
that perhaps they should be defining this key binding
in the Java Editing 
context only.

Second, as an editor you can define your own context
- say 'Editing with 
XML Buddy'. In one line of Java code you can associate
this context with
your editor. When your editor is active, key bindings
in your context will
be preferred over all others. Even without JDT contextualizing
their
Navigate -> Open Declaration key binding, you can
still override it in your
editor using this method. 


> - Several plug-ins (Java is the worst offender)
grab global accelerator 
> key assignments, effectively removing them from the pool available
to 
> other plug-ins.
>
> - The number of accelerator keys land-grabbed
by Eclipse continues to 
> grow at an alarming pace. Soon there will be no keys at all left over
> for new plug-ins to use.

You are correct. JDT takes too many nice keys in my
opinion.

As part of plan item 37934, we (the platform ui team)
offered to steward 
key binding assignments across the eclipse SDK, not
just to recover some
keys for ISV plugins, but also to ensure a cohesive
set. 

To that end, Doug Pollock produced a 'Standard 3.0'
set. 
One of the good things about this set is that it took
advantage of 
our ability to have multi key stroke key bindings
(like emacs). 
These 'ain't just for emacs anymore'. Visual Studio
now leverages this 
mechanism to increase its range key bindings.

Work on this set, as well as other key bindings /
commands work has 
unfortunately been deferred by management in favor
of other items. 
(Most of our team is working on the 'new look' now..)
Contexts is your 
best option here - simply take the keys you need while
your plugin is 
active. (You still will have to struggle to find available
key sequences 
for those actions you want to have a global key binding)


Please make sure to use bugzilla where appropriate..

Thanks,
Chris.