Comment 1 by jteh on 2011-02-28 02:05
First, this does not affect speaking of typed characters. For users, this only affects input help.

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.
Changes:
Milestone changed from None to 2011.2

Comment 2 by pvagner on 2011-02-28 08:09
Do I assume correctly that now it is inpossible to bind keys such as & on a french keyboard because people won't be able to press it?
For slovak keyboard it's not such a big deal because on that row we only have non-ascii characters mostly.
Anyway now when it's possible to override keyboard layouts for the locale, we might actually be able to fix it and let contributors working with language files also contribute keyboard layout deviations where needed.
Perhaps we should ask translators about it if they agree.

Comment 3 by jteh on 2011-02-28 08:48
Peter: Partially correct. The "&" key can be bound, but you have to specify it as "1". This was always the case. The regression only relates to the reporting of keys in input help/command keys.

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
Replying to jteh:
Jamie,

For me, the current behaviour may introduice some confusion for users.
For example, if a command is assigned to NVDA+1, you don't really know if it is NVDA+é or NVDA+shift+é.
So it would be beter to get the actual key name even having to change translation for next releases.

Peter: Partially correct. The "&" key can be bound, but you have to specify it as "1". This was always the case. The regression only relates to the reporting of keys in input help/command keys.

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 5 by jteh (in reply to comment 4) on 2011-02-28 09:18
Replying to msuch:

For me, the current behaviour may introduice some confusion for users.

For example, if a command is assigned to NVDA+1, you don't really know if it is NVDA+é or NVDA+shift+é.

Interesting. I get "&" when I press 1 on French (France) keyboard layout. Anyway...

So it would be beter to get the actual key name even having to change translation for next releases.

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
Replying to jteh:

Replying to msuch:

For me, the current behaviour may introduice some confusion for users.

For example, if a command is assigned to NVDA+1, you don't really know if it is NVDA+é or NVDA+shift+é.

Interesting. I get "&" when I press 1 on French (France) keyboard layout. Anyway...

Oops, sorry, 1 is & not é as I wrote.

So it would be beter to get the actual key name even having to change translation for next releases.

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".

I think we should have é and Shift+é which better describe the actual gesture.

Another question: if you want "é:" and not "1", why do you document "1" in the French mUser Guide?

Because I missed it! Is it still time to send a fixed version?

Comment 7 by pvagner on 2011-02-28 17:16
oops guys. I think we should leave this as is.
I know initially it may sound logical to use & and shift+& for the french layout however no other applications report key gestures this way. It's a pseudo standard and everywhere I can see 1 and shift+1 .
Jaws does it too for example to jump to the various heading levels.
Adobe audition, audacity all the applications refer to these shortcut keys as numbers eventhough they are in fact not on lot of keyboard layouts.
Doing this would mean people won't be able to use NVDA properly with their layouts unless there is a connection between keyboard layout and NVDA's gesture map.

Comment 8 by msuch (in reply to comment 7) on 2011-02-28 17:49
Replying to pvagner:

oops guys. I think we should leave this as is.

I know initially it may sound logical to use & and shift+& for the french layout however no other applications report key gestures this way. It's a pseudo standard and everywhere I can see 1 and shift+1 .

Jaws does it too for example to jump to the various heading levels.

Adobe audition, audacity all the applications refer to these shortcut keys as numbers eventhough they are in fact not on lot of keyboard layouts.

Doing this would mean people won't be able to use NVDA properly with their layouts unless there is a connection between keyboard layout and NVDA's gesture map.

Ok Peter, I understand your point of view.
It's true that the current naming is some kind of standard.
So, if we all agree, we could maybe close this ticket for now.

Comment 9 by jteh on 2011-03-01 11:01
Closing as per comment:7 and comment:8.
Changes:
Added labels: wontfix
State: closed