New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with keyboard input and french keyboard #1391
Comments
Comment 1 by jteh on 2011-02-28 02:05 The problem here is that before 2011.1, NVDA had separate code for determining the key names reported in input help and the key names it used internally. This was inconsistent and therefore not a good situation. Now, there is only one piece of code and it is closer to the code which used to determine internal key names. A long time ago (24a6a17), this internal key name code was changed to always use the ASCII representation for key codes in the ASCII printable range. This was done so that, for example, NVDA+1 would work on a French keyboard. Without this, NVDA+1 would actually be NVDA+&, which wouldn't work. (It's not possible to press NVDA+1 on a French keyboard without doing NVDA+shift+1 or turning on caps lock.) I think the correct solution is for us to remove this ASCII hack from NVDA. However, this would require French and other affected layouts to implement alternative key bindings for some keys; e.g. NVDA+& as well as NVDA+1. This is probably not something we want to do at this late stage of the release, as it will require User Guide changes and a lot of testing. Another solution is to try to split the code for determining names again, but this is pretty ugly. |
Comment 2 by pvagner on 2011-02-28 08:09 |
Comment 3 by jteh on 2011-02-28 08:48 Even if we do fix this bug, note that only the unshifted key would be reported. For example, in input help for French, you will hear "&" and "shift+&", regardless of whether caps lock is on or off. The question is: would you prefer to refer to that key as "&" or "1"? If you'd prefer to refer to it as "&", long-term, the French locale should override all key bindings involving these keys in its locale gesture map and change the User Guide accordingly. So, for French, toggle input help would be NVDA+&, not NVDA+1. Similarly, move to next/previous heading1 for virtual buffers would be & and shift+& instead of 1 and shift+1. I'd appreciate feedback on this. Note that this will affect many other languages as well. For 2011.1, we've decided to implement a hack to get back the inconsistent 2010.2 behaviour; e.g. input help will report "&", but NVDA will internally use "1". |
Comment 4 by msuch (in reply to comment 3) on 2011-02-28 09:12 For me, the current behaviour may introduice some confusion for users.
|
Comment 5 by jteh (in reply to comment 4) on 2011-02-28 09:18
Interesting. I get "&" when I press 1 on French (France) keyboard layout. Anyway...
Define "actual key name". Do you want "é" and "shift+é" or "1" and "shift+1"? It isn't possible to do something in between; it is one or the other. Also, if caps lock is on, the key in this example will still be reported as "é", not "1". Another question: if you want "é:" and not "1", why do you document "1" in the French mUser Guide? |
Comment 6 by msuch (in reply to comment 5) on 2011-02-28 09:52
Oops, sorry, 1 is & not é as I wrote.
I think we should have é and Shift+é which better describe the actual gesture.
Because I missed it! Is it still time to send a fixed version? |
Comment 7 by pvagner on 2011-02-28 17:16 |
Comment 8 by msuch (in reply to comment 7) on 2011-02-28 17:49
Ok Peter, I understand your point of view. |
Comment 9 by jteh on 2011-03-01 11:01 |
Reported by msuch on 2011-02-25 10:22
The problem occurs with 2011.1, did not exist with previous versions.
Keyboard input handles keys regardless of keyboard type (english, french etc).
You can see it when switching to input help mode.
On a french keyboard, the first row of keys contains special characters when caps lock is off and numbers when caps lock is on.
When help mode is on (and probably al times) keys are identified like 1 2 3 etc even when caps lock is off.
The text was updated successfully, but these errors were encountered: