Pcbnew: Hotkeys Ctrl+W, Ctrl+M, Ctrl+R are ignored

[Michael Geselbracht]

The hotkeys Ctrl+W, Ctrl+M and Ctrl+R have stopped working.
Linux and Windows(*) builds are affected.

Steps to reproduce:
1. Start pcbnew and open the 'pic-programmer' demo board
2. Move mouse cursor over a footprint (e.g. P3)
3. Press 'Ctrl-M' (Move Item) -> nothing happens

Reverting commit bd85421da resolves this issue (only tested with a linux build).

*) kicad nightly c01686196

Application: kicad
Version: (6.0.0-rc1-dev-1233-g630baa372), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-38-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.65.1
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.58.0
    Compiler: GCC 7.3.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_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=OFF

[John Beard (john-j-beard)]

I also see this on Linux GTK+ 3 (master: ad9916a93).

[Jeff Young (jeyjey)]

WxWidgets maps ctrl-letter combinations to 1..26 corresponding to Ctrl-A..Ctrl-Z. Trouble is that this places Ctrl-M at 13, and Ctrl-Enter also comes in as a 13. (Same for Ctrl-H and Ctrl-Tab, etc.)

I implemented a fix for this which checks both GetKeyCode() and GetUnicode(), which works on Mac (for Ctrl-M GetKeyCode() returns the mapped 13, but GetUnicode() still returns the unmapped 77).

Evidently this does not work on GTK. It's possible GetUnicode() is returning lower-case M (109), or that it's returning the mapped code (13), or something else. Of course I can't test any of these hypothesis as I don't have GTK.

If it returns 109 then expanding the test to:
    if( unicode >= 'A' && unicode <= 'z' && key >= WXK_CONTROL_A && key <= WXK_CONTROL_Z )

should fix it.

@John, could you set a breakpoint (tooldispatcher.cpp line 400) and see if Ctrl-M results in the local variable 'unicode' being 109? Thanks.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 37f062d32500c8fdc3047332bd87a5ebeb6b8f41
https://git.launchpad.net/kicad/patch/?id=37f062d32500c8fdc3047332bd87a5ebeb6b8f41

[jean-pierre charras (jp-charras)]

@Jeff,
I committed a fix for Windows and Linux.
OSX code should not be modified.

About Modifiers (Shift and Ctrl), they work fine *only* with 'A' to 'Z' keys.

With other keys, the result is unpredictable, because it depend on the OS and the locale.

In other words, Ctrl+Tab and Ctrl+Enter should not be used (at least as default hotkeys)

You don't know what happens on a given OS + a given Window manager + the current locale.

Trying to fix this kind of issue is wasting your time and can just create more issues.

[Maciej Suminski (orsonmmz)]

Looking at the debug output with WXTRACE=KICAD_KEY_EVENTS, it appears that EDA_DRAW_FRAME::OnCharHook() gets the correct key codes, but even though the event is skipped and there is an appropriate handler connected in TOOL_DISPATCHER, it never arrives there. Perhaps fixing the event routing would solve our issue.

[jean-pierre charras (jp-charras)]

Be *extremely* careful when testing/modiying something in OnCharHook() and OnChar() management.
The 3 platforms are very different.
This is not the first time we are fighting against this kind of issues, and hotkeys + shortcuts management are very tricky.

One can fix these issues on a given platform, but the fix does not work on others platforms.

This bug report is a perfect example of these issues.