Bug 6517 - [Key Bindings] Mechanism to change global-action accelerators for viewer scope
Summary: [Key Bindings] Mechanism to change global-action accelerators for viewer scope
Status: RESOLVED DUPLICATE of bug 5682
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 1.0   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Eduardo Pereira CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate
Depends on:
Blocks:
 
Reported: 2001-12-03 15:05 EST by adrian CLA
Modified: 2002-09-05 15:44 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description adrian CLA 2001-12-03 15:05:19 EST
1.- Here's the original Eclipse corner append:

Subject: Need mechanism to change global-action accelerator
Date: 17 May 2001 14:06:17 GMT
Newsgroups: eclipse.tools

I need a mechanism to easily change the accelerator of a global action in
the scope of the currently active viewer.

My text editor supports various key behaviors, such as emacs and vi.  For
example, in emacs, Ctrl+S is defined as "Search". However, the desktop
hardcodes Ctrl+S (and also takes over it, so the viewer doesn't receive a
KeyEvent for it) for the global action "Save".  While my editor is the
active window, I need to be able to remove the accelerator from the
desktop's "Save" (save in emacs is Ctrl+X,Ctrl+S), and receive the Ctrl+S
key in my KeyListener like any other key.  For some global actions, a new
accelerator may have to be set (rather than just removed as is the case
for this example) while my editor is the active keyboard-focus window.

[ This could be accomplished by updating the desktop accelerators for the
actions attached to it in IActionBars#setGlobalActionHandler(), as called
in BasicTextEditorActionContributor#setActiveEditor(). ]

2.- Bugzilla Bugs 1920, 1921 are related, but do not cover this requirement.

3.- In order to adequately support other editor personalities,
(a) the editor should have better control over its keys than now available - it 
should be the first to receive them, so it can 'consume' the keys it needs, and 
let the others be further handled by Eclipse;

(b) it should be able to modify the global Eclipse accelerators when it becomes 
active/non-active:
- query what's been defined by Eclipse
- change/remove the accelerators which conflict with its own when it gets focus, 
restore the original ones when it loses focus.
Comment 1 Simon Arsenault CLA 2001-12-10 14:43:11 EST
A proposal for Key Bindings is now being discussed on the eclipse ui mailing 
list (proposal is available from eclipse website in ui team page). Please read 
and comment.

Note, the proposal is recommending against editors defining their own key 
bindings. That is, the user should select the type of key binding he/she wants 
(for example, emac like accelerator keys) and have this applied to all actions 
in the UI in a consistent way no matter what editor is active. If the 
accelerator keys change for common actions (like save, close, cut, search, etc) 
depending on what editor is active, the user will get quickly confused.
Comment 2 Simon Arsenault CLA 2002-05-27 11:38:00 EDT
Defer until after release 2.0
Comment 3 Randy Giffen CLA 2002-08-08 17:12:00 EDT
Reopen for investigation
Comment 4 Eduardo Pereira CLA 2002-09-05 15:44:31 EDT
Some keybinging extension points have being implemented but we still need a UI 
so that the user can configure the diffenrent bingings.

*** This bug has been marked as a duplicate of 5682 ***