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
