Bug 307992 - [KeyBindings] Regression: Ctrl+1 doesn't call quick fix on AZERTY keyboard
Summary: [KeyBindings] Regression: Ctrl+1 doesn't call quick fix on AZERTY keyboard
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.6   Edit
Hardware: PC Windows All
: P3 normal with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: accessibility
Depends on: 289520
Blocks:
  Show dependency tree
 
Reported: 2010-04-02 10:47 EDT by Nicolas Bros CLA
Modified: 2021-11-16 13:56 EST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Bros CLA 2010-04-02 10:47:37 EDT
"Quick fix" is bound to the "Ctrl+1" keybinding.
But on a keyboard with an "AZERTY" layout, this doesn't work. I have to change it to "Ctrl+&" to make it work as intended.

This worked in Eclipse 3.5.
Comment 1 Markus Keller CLA 2010-04-06 04:56:21 EDT
Which build?
Comment 2 Nicolas Bros CLA 2010-04-06 11:31:55 EDT
Build id: I20100312-1448
Comment 3 Markus Keller CLA 2010-04-06 14:08:56 EDT
SWT's Snippet25 gives this on HEAD:

DOWN: stateMask=0x40000 CTRL, keyCode=0x26 '&', character=0x26 '&'

On 3.5.2, when I comment out the lines about keyLocation, it gives:

DOWN: stateMask=0x40000 CTRL, keyCode=0x31 '1', character=0x31 '1'

=> keyCode has changed due to bug 285656 (in class Widget). I assume that change was intended, so WorkbenchKeyboard#generatePossibleKeyStrokes(Event) and SWTKeySupport need to be adapted to restore the behavior from 3.5 for such keyboards (but keep the existing behavior for e.g. the US keyboard).

Problem: How can Platform UI find out that Shift+& on a French keyboard gives '1'? I fear we need new API for that (bug 289520 requests something similar).
Comment 4 Felipe Heidrich CLA 2010-04-13 09:18:07 EDT
"keyCode=0x26 '&'" is correct, agreed ?


I think the fix is to use a different set of keybindings depending on the physical keyboard layout.
Comment 5 Markus Keller CLA 2010-04-13 10:48:15 EDT
> I think the fix is to use a different set of keybindings depending on the
> physical keyboard layout.

In principle, yes. The problem is that we only use a single locale in Eclipse, but in the OS, there are at least 3 (UI language, keyboard language, number formats,...).

We know that many users run with a locale that is different from their keyboard locale, so changing key bindings based on the locale always causes ripples.

I checked some other applications, and they all execute Ctrl+<digit> without needing the Shift key with the "French (France)" layout, e.g.:
- Firefox (switches to 1st, 2nd, etc. tabs)
- Word (Ctrl+1 and Ctrl+2 toggle line spacing)
- Acrobat Reader (changes zoom levels)
Comment 6 Felipe Heidrich CLA 2010-04-13 16:31:47 EDT
(In reply to comment #5)
> > I think the fix is to use a different set of keybindings depending on the
> > physical keyboard layout.
> In principle, yes. The problem is that we only use a single locale in Eclipse,
> but in the OS, there are at least 3 (UI language, keyboard language, number
> formats,...).

Right, that is why I said to use the physical keyboard layout and not logical layout. But I don't know if you have that information available.

> I checked some other applications, and they all execute Ctrl+<digit> without
> needing the Shift key with the "French (France)" layout, e.g.:
> - Firefox (switches to 1st, 2nd, etc. tabs)
> - Word (Ctrl+1 and Ctrl+2 toggle line spacing)
> - Acrobat Reader (changes zoom levels)

I bet these application are using real shortcut accelerators (MenuItem#setAccelerator()), which use the raw key down input to fire the action.

I don't think there is any work I can do here, should we close this bug as duplicate of bug 289520 ? Or depends on bug 289520
Comment 7 Markus Keller CLA 2010-04-14 05:18:29 EDT
I marked it as depends on bug 289520 (since there's still work to do in Platform/UI after that bug has been fixed).

"Ctrl+<the unshifted &/1 key>" didn't invoke Quick Fix in 3.3 but did in 3.4 and 3.5 (side effect of bug 219582). In 3.6, we're back to the behavior from 3.3.
On GTK, it also doesn't invoke Quick Fix in 3.6 (and AFAIK never did).

We can look at this again when bug 289520 has been fixed (see comment 3).

Workaround for now is to also press Shift (which in a way makes sense because "1" is really "Shift+&" on the French keyboard), or to assign Ctrl+& to the command.
Comment 8 Lars Vogel CLA 2019-11-08 04:38:36 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

If the bug is still relevant please remove the stalebug whiteboard tag.
Comment 9 Nicolas Bros CLA 2019-11-09 12:51:07 EST
The bug is still there even on 4.14 M1.
The default shortcuts don't work with an AZERTY keyboard layout: for these shortcuts to work I need to go to Preferences > General > Keys and replace Ctrl+1 by Ctrl+&, Ctrl+2 by Ctrl+é and Ctrl+3 by Ctrl+"
Comment 10 Eclipse Genie CLA 2021-11-16 13:56:07 EST
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.