kicad-developers team mailing list archive

[Duane Johnson <duane.johnson@xxxxxxxxx>]

This is worse than web development. And that's saying something :)

On Fri, Jan 8, 2016 at 11:16 AM, Chris Pavlina <pavlina.chris@xxxxxxxxx>
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
>
>