kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 1/11/2016 2:16 PM, Chris Pavlina wrote:
> Had to change the capture method for both reasons. The old wxListCtrl 
> (IIRC) was the _only_ widget that captured them correctly.

Maybe that's why the person who design the original hotkey dialog end up
using wxListCtrl.  It's certainly something to consider.  I know it
doesn't layout as nice as the tree control.

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

Thanks.

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