kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

Hello, Chris!

I was testing the hotkeys in bzr 6494.

Duplicate hotkeys still don't get recognized when there is
the Alt-key envolved.
I am able to assign i.e. Alt-W or Ctrl-Alt-E to several
commands at the same time.

Ctrl-Tab ist still assigned as Ctrl-I (well, it's not
nice but not a show-stopper).

Maybe you want to verify and fix these issues.

Regards,

Clemens

On 2016-01-16 03:10, Chris Pavlina wrote:
> Okay, I merged this - I'm still not 100% clear whether or not you wanted 
> me to, but it's been quite a while and I've fixed what you told me to 
> fix - feel free to revert if I'm wrong.
> 
> On Wed, Jan 13, 2016 at 09:36:13PM -0500, Chris Pavlina wrote:
>> Want me to commit this?
>>
>> On Mon, Jan 11, 2016 at 09:27:49PM -0500, Chris Pavlina wrote:
>>> Looks like the text overflow was actually a wx bug - it insisted on 
>>> computing the size of the wxStaticText based on the smaller default font 
>>> instead of the larger one I had set.
>>>
>>> Easily solved by just not setting a larger font. Still looks fine.
>>>
>>> Patch attached.
>>>
>>> On Mon, Jan 11, 2016 at 03:32:00PM -0500, Wayne Stambaugh wrote:
>>>> 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
>>
> 
> _______________________________________________
> 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
>