kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

Chris,

I just finished testing this and I'm not sure about using a dialog to
capture the hotkey press.  Did you have to do this to overcome using the
tabbed dialog or was it due to changing the control to a tree control?
If it's the tabbed dialog design, it might be worth leaving the hotkey
assignment dialog as a separate dialog.  If not, I guess I can live
with it but it wasn't necessary with the previous hotkey dialog.  One
other thing, you might want to avoid is using bold characters in the
hotkey capture dialog.  They are getting truncated on my windows builds.
 The longer the description, the worse the truncation.

Cheers,

Wayne

On 1/8/2016 1:16 PM, Chris Pavlina wrote:
> Hi,
> 
> Jesus, here be dragons. Finally got the hotkeys stuff working properly 
> on all platforms - this has been tested on Linux, Win10, and OSX. Thanks 
> to JP for a push in the right direction (and even that required more 
> work!).
> 
> Quick summary of the problems:
> 
>     - On Windows, there is a bug/quirk somewhere, where if a Tab 
>       keypress occurs in a dialog with nothing in the tab order, this 
>       must NOT generate the corresponding wxEVT_CHAR. If this happens, 
>       the entire application freezes solid. This has nothing to do with 
>       wxTAB_TRAVERSAL, so disabling this style property does not help.
> 
>     - wxEVT_CHAR_HOOK can be used to catch this event early and block 
>       the tab bug. It also has the benefit of catching other 'special' 
>       keys that wxEVT_CHAR misses (again, on Windows. wxEVT_CHAR has no 
>       problem receiving them on Linux).
> 
>     - .../however/, wxEVT_CHAR_HOOK reports some keys incorrectly. Any 
>       shifted symbol keys are reported as shift+(the unshifted key), so 
>       on a US keyboard for example, when you type <?>, it sees 
>       <Shift>+</>. There's no easy way to map these to the "correct" 
>       keys, particularly considering international keyboards.
> 
>     - When wxEvent::DoAllowNextEvent() is called (see below), 
>       wxEvent::Skip MUST be called on Linux and OSX, and must NOT be 
>       called on Windows. No... I don't know why.
> 
> In the end, I implemented separate OnChar and OnCharHook handlers. 
> OnCharHook does the following:
> 
>     1. If the keypress is a pure modifier (wxEVT_CHAR_HOOK generates 
>     events for things like Ctrl by itself), do nothing.
> 
>     2. If the keypress is for a printable character **that is not 
>     whitespace** (to avoid tripping the Tab bug), call 
>     wxEvent::DoAllowNextEvent to cause the wxEVT_CHAR for the same key 
>     to be generated. Call or do not call wxEvent::Skip depending on 
>     platform, as above. This causes the "correct" key to be looked up 
>     (e.g.  <?> instead of <Shift></>) and this progresses to the OnChar 
>     handler.
> 
>     3. For all other keys, do not allow the wxEVT_CHAR to be generated, 
>     but instead pass the event object directly to OnChar.
> 
> 
> Then OnChar handles returning the keycode to caller.
> 
> Please, help me test this. Wayne, if this works, and you don't mind, I'd 
> really like to get it merged. Even if there are still minor GUI quirks 
> and whatnot, the current top of the devel branch has the hotkey bugs 
> from earlier that I'd like to get fixed. Any further minor issues can be 
> resolved in further minor commits.
> 
> --
> Exasperatedly,
> Chris
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>