kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

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
>