kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 21/01/2016 04:44, Chris Pavlina a écrit :
> There is an old bug that people turned up while testing my new hotkey 
> editor, attached is a patch that fixes it. This patch pokes into the 
> main hotkey handling code, so I really want as many people to test it as 
> possible - it's a relatively minor bug, I don't want to go introducing 
> twelve regressions to fix one small bug. Here's what I want to keep an 
> eye out for:
> 
> - Hotkeys (Ctrl+Tab), (Tab), and (Ctrl+I) are all independent and 
>   distinguished from each other, both in the hotkey editor and in actual 
>   use. Make sure all of them work, and make sure none of them answers 
>   for the others.
> 
> - Hotkeys that are *not* handled by the main hotkey code (for example, 
>   menu keys like Alt+F to call up the File menu) are not affected.
> 
> - Behavior on OSX, with its weird Ctrl mapping, is not broken (or, at 
>   least, is no more broken than usual ;)
> 
> I have tested on Linux and Windows 10, though more thorough testing on 
> those platforms is welcome.
> 
> Patch/bug summary:
> 
> [PATCH] Fix (Ctrl)+(ASCII control key) hotkey handling
> 
> wxWidgets has quirks with how it handles these keys. For example, in
> wxEVT_CHAR, Ctrl+Tab and Ctrl+I are indistinguishable.
> 
> - Modify the special wxEVT_CHAR_HOOK handler from WIDGET_HOTKEY_LIST to
>   handle this case as well as the other funny cases it already handles.
> 
> - Factor this handler out into a function in hotkeys_basic.h for use
>   elsewhere.
> 
> - Add this handler to the central hotkey handler, remove existing
>   (buggy) ASCII control key handling.
> 
> Thanks for testing.

I tested it on W7 32. No problem.

However during tests, I saw a regression:
in Eeschema only, hotkeys are no more saved.
When a hotkey is changed, after closing and rerun Kicad, the default
hotkey if used (the change is lost).
And no xx.hotkeys is created after changing a hotkey in Eeschema.



-- 
Jean-Pierre CHARRAS