Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] multiple Keybinding configurations in the plan?

There is a committed plan item for improving key bindings, although we 
will not be looking at this for milestone 2.
Could you please capture the details below there?
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37934

Thanks,
Nick





Randy Hudson/Raleigh/IBM@IBMUS
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
07/02/2003 10:31 AM
Please respond to platform-ui-dev
 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        [platform-ui-dev] multiple Keybinding 
configurations in the plan?



I am digging up a previous topic, the single keybinding configuration for 
the workbench: 

Having a single keybinding configuration for the entire workbench is not 
sufficient.  Currently, the user can choose between "default" and "emacs" 
modes.  These modes only make sense for source editors, and do not apply 
to other types of editors, such as HTML editors. 

An HTML editor might define new configurations called "frontpage" and 
"dreamweaver".  Now, if the user wishes to activate both "dreamweaver" and 
"emacs", which makes sense because these are completely orthogonal 
functions, he cannot. 

Perhaps the solution is to add a new concept called a "domain", or some 
other vague grouping terminology <g>.  And, since the current UI for 
editing keybindings does not scale very well, it might make sense for 
plug-ins to start re-using the keybinding page under their own preferences 
subtree, instead of just adding and adding more and more entries into a 
global one.  This way, domains wouldn't be exposed to the user, but would 
be implied by the place where they found the keybinding page, for example, 
"Webtooling->HTML Keybindings". 

As was discussed last time I brought this up, a workaround is to have the 
HTML editor use scopes as the way to implement its configurations.  But 
this means that the HTML editor cannot use scopes for what they were 
intended, so it could not define a "JSP" scope which inherited from the 
"HTML" scope. 

history: 
http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg00829.html 
http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg00834.html 

-randy



Back to the top