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 : [email protected] > >>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>> Post to : [email protected] > >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>> Post to : [email protected] > >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>> Post to : [email protected] > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>> More help : https://help.launchpad.net/ListHelp > >> > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
