kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

It seems like this may be one of those issues where we have to
compromise on the design.  Once you figure out the hotkey entry dialog
text overflow issues I'm fine with committing the changes.  Everything
else seems to work as expected.

On 1/11/2016 3:00 PM, Chris Pavlina wrote:
> Well, yes, that would be why it was selected. I don't like the idea of 
> limiting ourselves so much (must be wxListCtrl, must be an otherwise 
> mostly empty dialog) just because of a quirk of the way wx processes 
> events, though, and IMO the dialog method isn't all that bad. Nice and 
> clean with the way events are handled and received (except for the few 
> weird quirks I ranted about earlier, but those are nicely isolated now). 
> We can put that in any control in any layout we want without 
> restriction.
> 
> Also I'd argue that just accepting the hotkeys directly in the dialog is 
> rather poor UI design /anyway/. It disables the normal navigation keys, 
> such that a user cannot operate the hotkeys list with the keyboard the 
> way he can operate the other controls, and works in a unique way to any 
> other programs, making it non-obvious. Pretty much everything I've seen 
> uses something different from that.
> 
> The one I _really_ like is KDE, which places a button /in/ the list 
> control under the selected item. You click the button, and then as far 
> as I can tell the button receives the event. I tried. wx makes this 
> almost impossible. :(
> 
> 
> On Mon, Jan 11, 2016 at 02:51:26PM -0500, Wayne Stambaugh wrote:
>> 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
>>>
>>
>> _______________________________________________
>> 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