Community
Participate
Working Groups
(This is actually for Eclipse 3.0, I guess...) A window should have first chance at processing its keys; then its parent / shell windows should only process (for e.g., top-level menu mnemonics resolution, etc.) keys which were not yet consumed. This is, by the way, how it is done in AWT/Swing. This will solve serious conflicts between a focus window's keys and other keys defined in the application - e.g., a window's Alt+<key> combinations and the application's top-level menu mnemonics (also activated by Alt+<key> combinations), which are 'dynamic' - i.e., depending on the plugins installed, running environment's locale, etc. Below's selections from correspondence on the subject in platform-ui-dev mailing list (May 2002, under title "Proposed accelerator change: using Ctrl+Shift+B for build"), in latest-to-oldest order. -------------------------------------------------------------------------------- I was wondering whether the traverse-listener mechanism could be used. It currently works fine in empowering a window and letting it handle on its own the Tab, Shift+Tab, Esc, Enter, and arrow keys, informing the higher levels that the traversal should not be done by setting event.doit = false. It could be similarly employed for TRAVERSE_MNEMONIC (to let the window stop menu-mnemonic activation for its own key combos), and for (a new) TRAVERSE_ACCELERATOR (similarly, for higher-level/Eclipse global-action accelerators). -- Adrian. -------------------------------------------------------------------------------- Please investigate ways that this can be supported on all platforms which Eclipse runs on and report your results to the platform-swt-dev mailing list. Our current belief is that this can not be done while maintaining the use of the native accellerator/mnemonic mechanisms. -- McQ. -------------------------------------------------------------------------------- I'm working on the LPEX editor, which has various key profiles (emacs and others), independent of the Eclipse settings (emacs or other). The capability of giving a window a chance to process keys before menu mnemonics should be generally available, not hacked for a specific case. -- Adrian. -------------------------------------------------------------------------------- For our emacs keybinding support, the editor should get the key before the menu mnemonic (we are going to extreme measures to whack the mnemonics and accelerators to support this). Do you have a case where this is not so? -- Nick Edgar. -------------------------------------------------------------------------------- I was refering to a window's *accelerators* (shorcuts) - such as Alt+<letter> combinations in, say, an emacs editor view - being 'stolen' by Eclipse's top-level menu mnemonics (also activated by Alt+<letter>). -- Adrian. -------------------------------------------------------------------------------- It is not recommended to use mnemonics for controls in a main window, other than for the menus, precisely for this reason. You cannot predict whether there will be conflicts. And even if we did allow bottom-up lookup of mnemonics, it would be confusing to the user to see duplicates. See item 9 in the Accessibility Tips off our development resources page: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/accessi bility/tips.html -- Nick. -------------------------------------------------------------------------------- Nick wrote: > We can't second guess what accelerators > will be needed for products above us. Top-level menu mnemonics in particular are a big issue, as they steal Alt+<letter> combinations. Not only additional plug-ins may add their own top-level menus, but once a product gets translated (Spanish, French, etc.), all these Alt+<letter> will now steal *different* letters... -- Adrian. -------------------------------------------------------------------------------- This will not happen for R2.0. Feel free to post a feature request against SWT for consideration for R3.0 -- McQ. -------------------------------------------------------------------------------- Nick wrote: > Ideally the editor could define Ctrl+B for bold, and that would have > precedence over any global shortcut when in that editor. > However, the current keybindings support does not allow this. SWT always > processes accelerators first, so the editor would never see it. I c o n c u r ! ! ! I've asked for this myself (in other posts). AWT/Swing also first lets a window handle its own keys, and only processes (mnemonics resolution, etc.) what's not been consumed. Should perhaps a request be opened for this (given that there are any chances to get it actually implemented)? -- Adrian. -------------------------------------------------------------------------------- Is there any way that the accelerator could act differently based on the active part/editor? When writing in a java editor, Ctrl+B makes sense for build, but when writing HTML Ctrl+B for bold makes the most sense. I think the contexts are different enough that a different keyboard mapping for those actions would be acceptable. Alternatively, don't we have a mechanism now so that other products can ship with a different set of key bindings from the base SDK? In the Eclipse SDK, Ctrl+B for bold is wasted, but in other products they should be able to redefine it to mean whatever makes the most sense for their product. We'll never arrive at a set of global accelerators that doesn't create some conflict between tools. There's just too many products built on top of eclipse that have different accelerator requirements, and not enough keys on the keyboard. Just my two cents.... Nick said: >We are considering changing the accelerator for Build to Ctrl+Shift+B. > This is to address: > [Bug 16112] New: Conflict of keyboard shortcut key (Ctrl+B) > http://bugs.eclipse.org/bugs/show_bug.cgi?id=16112 -- John Arthorne.
Thanks for capturing the discussion. Need SWT support for this. Defering.
Reopened for investigation
SWT team has given us a pattern of code so we can implement keybinding without this support. It is a bit of a hack but it is isolated and acceptable. The code is released in the 2.1 stream and being tested. So we may not need this support. Will keep the PR opened until we prove that this "solution" works.
Re last comment (Eduardo Pereira 2002-09-05 13:10): Just to make sure: please note that I want to be able to process the keys myself in the focus window, and be able to indicate what I consumed (*this* is the problem reported in this bug) - I don't really care how Eclipse keybinding will work (afterwards in the chain).
after much effort by the key bindings dynamic team over the last four months, this was a fundamental design consideration. it was decided that it would not be advantageous going forward to allow the focus window to process keys first. our developing action strategy will enforce that a window must properly register its actions with the workbench in order to participate in using key bindings.
Hi, although this feature request is set to Wontfix, I would like to ask for an implementation. The current solution might work with Eclipse, but other applications that use SWT as GUI library with no content-dependant hotkeys cant do anything about it (except removing all accelerators, as soon as the focus is set to an Input Field). Ben
