• PR introduces Flake8 errors
• Build (for testing PR)

See test results for failed build of commit b3bc3412d4

I have to say that from the end user perspective being able to set the shortcut right from the installer is a huge advantage - thanks for implementing this. I am however not sure that it would fix any of the above mentioned issues, as they are dealing with failures during creation of start menu shortcuts. @feerrenrut Have you seen This commend by @jcsteh ? Using the never shell interface which supports Unicode seems good way to go.

Yep, I saw that comment. This PR uses the newer shell interface, using win32/shell rather than wshell. From my testing it handled setting shortcut names to unicode characters successfully. During my investigation I found a specification (on MSDN) for the *.lnk (windows shortcut file) format, which shows lots of limitations for what the hotkey can be set to. We will have to validate the gesture against this. We should probably also make this possible from the NVDA settings.

There is another PR #10875 that I recommend we mitigate the issues in 2020.1 while this PR can target 2020.2 since it will need testing from a range of input locales.

One question is what the default should be. The following file shows languages that have translated the hotkey, several of these are invalid and likely cause errors langs_with_customized_hotkey.txt

Options that I can see for the default value for the shortcut:

1. Use ctrl+alt+n as per English
2. No value by default
3. Use ctrl+alt+n for all languages except those that currently have a valid shortcut defined in the translation files. Special case those languages instead.

Special casing those few languages adds more complexity, both to the code and to the documentation. There is trade off, though it's not the most important detail at this stage.

@feerrenrut wrote:

One question is what the default should be. The following file shows languages that have translated the hotkey, several of these are invalid and likely cause errors langs_with_customized_hotkey.txt

Options that I can see for the default value for the shortcut:

1. Use `ctrl+alt+n` as per English

That is IMHO not a good option. In Polish for instance this enters one of the national letters, and for less experienced uses changing this is impossible (I am still laughing when I recall my younger self uninstalling NVDA because of this)... It took a while to allow translators to translate the shortcut (see #2209)

3. Use `ctrl+alt+n` for all languages except those that currently have a valid shortcut defined in the translation files. Special case those languages instead.

Special casing those few languages adds more complexity, both to the code and to the documentation. There is trade off, though it's not the most important detail at this stage.

From end user perspective this looks as the best option, though I understand why it might be hard to implement.

In Polish for instance this enters one of the national letters, and for less experienced uses changing this is impossible

With this PR the shortcut can be changed during the installer, this should make it much easier. Does this address your concern?
We'll look at setting locale defaults based on current translations, but this is a complication that will need to be reflected in documentation. It's also an assumption that the NVDA language is the same as the input language. Some people may wish to read in one language, but have their input language / layout set differently. We could base the shortcut on input language instead, but this is complicated by the number of variations. It's also worth noting that changing language (input or NVDA) will not cause the shortcut to be automatically updated.

@zstanecic We could consider changing the invariant (English language) default, but this will affect the largest group of users. It is the largest because many other languages haven't overridden the default. I'd prefer not to do this, but thank you for the suggestion.

@zstanecic I'm attempting to impact as few people as possible. My assumption is that most people don't want the hotkey that they are familiar with to suddenly change. Anyone who wishes to have a different hotkey can use this new option in the installer to get their preference.

Just to add my two cents about CTRL+ALT+F5 and why I believe that this one is not really a good default

1. It cannot be used on never Macbooks equipped with touchbar if user is not familiar with it.
2. Some never laptops lacks function keys row completely, so unfamiliar user working on hardware not belonging to him might have difficulties running NVDA.
3. Most importantly on many keyboard function keys are used as a multimedia keys by default, so I can imagine a situation in which someone presses CTRL+ALT+F5 and inadvertently mutes the pc, making usage of the machine difficult without sighted help

I'm closing this PR with a preference for an alternative solution. Getting the hotkey capture implementation right will take a significant amount of time and the user stories it enables can be satisfied in easier ways. Instead we will take the following approach:

To support unicode characters in shortcut file names, which is specifically useful for the user guide and user config directory shortcuts.

• Action: Change the implementation for creating shortcuts to use the Win32/Shell/shelllinkobj api (as this PR does)
• This API is supported as far back as Windows XP / Server 2003
• It handles unicode file names
• Hotkeys must be defined as a number rather than a string. The process is documented in the attached links. To make the code easy to read and understand, the shortcuts should be defined as strings, and parsed according to the specifications in section 2.1.3 HotKeyFlags of the MS-SHLLNK document.

To ensure mistakes during translation of hotkey don't affect the install process in the future.

• Action: No longer translate the hotkey.
• Action: Make hotkey values hard coded in python for languages that already have hotkeys defined.
• Future: We could consider translating hotkeys again if automated tests were added to the translation system to ensure the hotkeys are valid. However this is out of scope for this work.

To support users who don't like the default hotkey for their language.

• Hotkeys for shortcuts can already be reconfigured by users via Windows by accessing the properties for the shortcut file.
• These hotkeys will not subsequently be modified by the NVDA installer, if the shortcut already exists it is not modified. This prevents users from losing their custom hotkey.
• Action: Add instructions for how to modify the hotkey to the NVDA user guide.