kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Thanks.

Don't remember if I said this, but Ctrl-Tab being picked up as Ctrl-I is 
an old issue - I do actually plan to fix this, though.

As for duplicate hotkeys not being recognized - do you still have an old 
build kicking around to test for me if this is a regression or not? I 
*think* it should behave the same there as it did before, as in the end 
the duplicate-check ended up being mostly the same code. I don't have a 
chance to dig into it right now, but I'll get to it soon.

-- 
Chris

On Mon, Jan 18, 2016 at 12:47:26AM +0100, Clemens Koller wrote:
> 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
> > 
> 
> _______________________________________________
> 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