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

Bug #1804326 reported by Michael Geselbracht on 2018-11-20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
jean-pierre charras

Bug Description

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
    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:

John Beard (john-j-beard) wrote :

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

Jeff Young (jeyjey) wrote :

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.

Jeff Young (jeyjey) on 2018-11-22
Changed in kicad:
milestone: none → 5.1.0
KiCad Janitor (kicad-janitor) wrote :

Fixed in revision 37f062d32500c8fdc3047332bd87a5ebeb6b8f41

Changed in kicad:
status: New → Fix Committed
assignee: nobody → jean-pierre charras (jp-charras)

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) wrote :

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.

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.

Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers