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
