Hotkeys requiring Shift don't work in numerous contexts

[fierst]

The "Properties" pane of the page layout editor doesn't accept input of the number 2 from the number keys in any of the text boxes (e.g., "Text Width", "Comment", etc.) However, entering '2' from the number pad works just fine.

When '2' is pressed from the row of number keys, it toggles the "Zoom to selection" feature despite the text box having focus. The hotkey for this function is bound to the '@' symbol, which on my keyboard layout is equivalent to "Shift + 2", and that key sequence also works to toggle this function. Strangely, I can enter '@' in any of these text boxes without an issue and it doesn't toggle the "Zoom to selection" function in the main window.

Version Info:

Application: pl_editor
Version: (5.0.0-rc2-dev-114-g8fcbb64a4), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

[Nick Østergaard (nickoe)]

This sounds like a keymapping issue of some sort involving some french keyboard layout assumption...

I can confirm this issue on widows

Application: pl_editor
Version: (5.0.0-rc2-dev-20-g55edf1aad), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1 librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

[Jeff Young (jeyjey)]

Not reproducible on Mac (with Irish/UK keyboard), lending weight to Nick's supposition.

[fierst (fierst)]

This seems to be a larger issue with hotkey handling in general; I just had it happen in the PCB editor as well. The hotkey for changing track posture is '/' and the hotkey for displaying the current hotkeys is '?', which on my keyboard (US layout, standard) is "Shift + /". Attempting to change the track posture brings up the hotkey window as it just ignores whether or not shift is pressed.

[Nick Østergaard (nickoe)]

Is your system locale also en_US?

[Wayne Stambaugh (stambaughw)]

@Jon, I don't think this is a problem you are going to solve quickly so I think rc2 is a bit optimistic but I could be wrong. I have a patch that fixes the '/', '?' key on us keyboards for the track posture switching hotkey issue on windows. The problem with my patch is that the behavior is different between the legacy and new tool framework so it only works in the legacy canvas. I sent the patch to Orson to see if he could figure out where the difference was occurring but he couldn't find the issue even using a debug build of wxwidgets. I was going to commit it as is but it's an ugly hack with #ifdef/#endif code because the behavior of this key is different between windows and linux. Given what I know (albeit limited) about keyboard mapping, I think we are going to have to rewrite the hotkey code to handle key mapping differences between platforms, keyboard styles, and locales.

[Jon Evans (craftyjon)]

OK, I just tagged it for RC2 to make sure we decide something (whether it is to try to fix it or to not try to fix it).

Can you send me your patch? I'm curious to play with it and also could do some testing on Mac as well as Win/Linux.

[jean-pierre charras (jp-charras)]

I modified the choice of the key 2 some time ago.
It is now Ctrl+F5.

This issue has nothing to do with a French keyboard.

It due to the fact the key 2 was an accelerator key (not a hotkey).
On windows, accelerator keys have a specific behavior:
- they do not take in account the Shift, when a key has 2 different codes (one when not shifted, an other when shifted)

- they have the higher priority, therefore if the key '2' is an accelerator key, it is 'captured' by the corresponding menu.

This is the reason most of accelerator keys are always Alt+ something or Ctrl+something.

This not specific to Kicad.
LibreOffice ( and other applications ) has the same behavior.

For instance, with a French keyboard, keys 0 to 9 are shifted keys:
for key 1:
not shifted = &
shifted = 1

However, if a accelerator key is Ctrl+1 on my keyboard I must type Ctrl+& and *not* Ctrl+Shift+& (It should be needed to type Ctrl+1, but this is not the case).

I tested that on LibreOffice and a other application, not only on Kicad.

This king of issue is more noticeable when using a French keyboard than a US keybord

[Wayne Stambaugh (stambaughw)]

Attached is the patch I sent to Orson. It only fixes the '/''?' key. I
haven't tested any of the other keys like '.''>' or ',''<'.

On 3/27/2018 10:13 AM, Jon Evans wrote:
> OK, I just tagged it for RC2 to make sure we decide something (whether
> it is to try to fix it or to not try to fix it).
>
> Can you send me your patch? I'm curious to play with it and also could
> do some testing on Mac as well as Win/Linux.
>

[Wayne Stambaugh (stambaughw)]

On 3/27/2018 10:23 AM, jean-pierre charras wrote:
> I modified the choice of the key 2 some time ago.
> It is now Ctrl+F5.

@JP, This was the zoom to selection shortcut key in the page layout
editor. I changed this because "Ctrl+F5" was available on all main
frames when I added zoom to selection shortcuts to all of the other
editor main frames.

>
> This issue has nothing to do with a French keyboard.
>
> It due to the fact the key 2 was an accelerator key (not a hotkey).
> On windows, accelerator keys have a specific behavior:
> - they do not take in account the Shift, when a key has 2 different codes (one when not shifted, an other when shifted)
>
> - they have the higher priority, therefore if the key '2' is an
> accelerator key, it is 'captured' by the corresponding menu.
>
> This is the reason most of accelerator keys are always Alt+ something or
> Ctrl+something.
>
> This not specific to Kicad.
> LibreOffice ( and other applications ) has the same behavior.
>
> For instance, with a French keyboard, keys 0 to 9 are shifted keys:
> for key 1:
> not shifted = &
> shifted = 1
>
> However, if a accelerator key is Ctrl+1 on my keyboard I must type
> Ctrl+& and *not* Ctrl+Shift+& (It should be needed to type Ctrl+1, but
> this is not the case).
>
> I tested that on LibreOffice and a other application, not only on Kicad.
>
> This king of issue is more noticeable when using a French keyboard than
> a US keybord
>

[jean-pierre charras (jp-charras)]

@Wayne,
Just or your info, a trick I discovered, but working only on Windows:

In menus, to avoid having a hotkey converted to a accelerator key (a shortcut) this trick work for me:
a accelerator key is added to the menu item string by:
<menu string> + "\t" + <accelerator key>
if the full menu item string is:
<menu string> + "\t" + ' ' + <accelerator key>
the "accelerator key" is no longer seen as a accelerator key by wxWidgets, and becomes just pârt of the the menu string.
This is a easy way to fix hotkeys versus accelerator keys on Windows.

Unfortunately, it does not work on Linux.

[Wayne Stambaugh (stambaughw)]

@JP, We used to do this but the problem with embedding the accelerator
key in the menu string is that keys are no longer user editable. I
think this is one of the primary issues with our current design. We
merged the hotkeys and accelerator keys so that the user could edit both
with the hotkey edit dialog but no distinction was made as to what type
of key is being edited. Now, everything is identified as a hotkey when
in reality that is not the case. I think this only increased the
confusion for both developers and users. We should take a look at this
during the v6 development cycle. I'm sure we can come up with a better
design than our current design and fix the key mapping issue at the same
time.

On 3/27/2018 1:59 PM, jean-pierre charras wrote:
> @Wayne,
> Just or your info, a trick I discovered, but working only on Windows:
>
> In menus, to avoid having a hotkey converted to a accelerator key (a shortcut) this trick work for me:
> a accelerator key is added to the menu item string by:
> <menu string> + "\t" + <accelerator key>
> if the full menu item string is:
> <menu string> + "\t" + ' ' + <accelerator key>
> the "accelerator key" is no longer seen as a accelerator key by wxWidgets, and becomes just pârt of the the menu string.
> This is a easy way to fix hotkeys versus accelerator keys on Windows.
>
> Unfortunately, it does not work on Linux.
>