kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Had to change the capture method for both reasons. The old wxListCtrl 
(IIRC) was the _only_ widget that captured them correctly.

I'm not completely a fan of the dialog either, but it's not all _that_ 
bad, and we're not the only ones doing it that way. At very least the 
XFCE settings dialog does that, as well as a few others I tested (that I 
don't remember right away). It's a pretty reliable way to make sure 
you're the only thing receiving an event.

I'll look at the labels - they weren't truncated in my Windows builds, 
but maybe I changed something and didn't realize it.

On Mon, Jan 11, 2016 at 02:11:36PM -0500, Wayne Stambaugh wrote:
> 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
> > 
> 
> 
> _______________________________________________
> 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