That's a bit odd. Ctrl-F seems to do nothing special. I just checked ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml
and didn't find Ctrl-F or anything "*Focus*". :-( I have to dig deeper. Never mind. BTW: The xfce4 settings editor looks really nice: http://wiki.pcbsd.org/images/0/03/SettingsEd.png Can kicad adopt something like that - not only for the hotkeys? Clemens On 2016-01-08 01:22, Chris Pavlina wrote: > Yup, your system is eating Ctrl-F. Don't know where it's going, though. > > The FocusIn/FocusOut events just mean that focus moved in and out of the > window. That could happen, for instance, if Ctrl-F were popping up a > dialog that took focus - but I suspect you'd notice that. > > On Fri, Jan 08, 2016 at 01:21:48AM +0100, Clemens Koller wrote: >> Hi, Chris! >> >> Output of xev while pressing Ctrl-F: >> >> KeyPress event, serial 37, synthetic NO, window 0x2000001, >> root 0x49b, subw 0x0, time 45842899, (172,-8), root:(2755,562), >> state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >> XLookupString gives 0 bytes: >> XmbLookupString gives 0 bytes: >> XFilterEvent returns: False >> >> FocusOut event, serial 37, synthetic NO, window 0x2000001, >> mode NotifyGrab, detail NotifyAncestor >> >> FocusIn event, serial 37, synthetic NO, window 0x2000001, >> mode NotifyUngrab, detail NotifyAncestor >> >> KeymapNotify event, serial 37, synthetic NO, window 0x0, >> keys: 2 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >> >> KeyRelease event, serial 37, synthetic NO, window 0x2000001, >> root 0x49b, subw 0x0, time 45843317, (172,-8), root:(2755,562), >> state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >> XLookupString gives 0 bytes: >> XFilterEvent returns: False >> >> >> Hmmm... >> No idea what these FocusOut FocusIn events are useful for? >> For comparison, pressing i.e. Ctrl-E delivers: >> >> >> KeyPress event, serial 37, synthetic NO, window 0x2000001, >> root 0x49b, subw 0x0, time 45886107, (173,-7), root:(3000,428), >> state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >> XLookupString gives 0 bytes: >> XmbLookupString gives 0 bytes: >> XFilterEvent returns: False >> >> KeyPress event, serial 37, synthetic NO, window 0x2000001, >> root 0x49b, subw 0x0, time 45886307, (173,-7), root:(3000,428), >> state 0x14, keycode 26 (keysym 0x65, e), same_screen YES, >> XLookupString gives 1 bytes: (05) "" >> XmbLookupString gives 1 bytes: (05) "" >> XFilterEvent returns: False >> >> KeyRelease event, serial 37, synthetic NO, window 0x2000001, >> root 0x49b, subw 0x0, time 45886387, (173,-7), root:(3000,428), >> state 0x14, keycode 26 (keysym 0x65, e), same_screen YES, >> XLookupString gives 1 bytes: (05) "" >> XFilterEvent returns: False >> >> KeyRelease event, serial 37, synthetic NO, window 0x2000001, >> root 0x49b, subw 0x0, time 45886447, (173,-7), root:(3000,428), >> state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, >> XLookupString gives 0 bytes: >> XFilterEvent returns: False >> >> >> >> Clemens >> >> >> On 2016-01-08 01:10, Chris Pavlina wrote: >>> Interesting bugs. >>> >>> I can confirm Ctrl-Tab becoming Ctrl-I -- however, I also tested that >>> in an old build before I touched the hotkey code, and it *still* does >>> that. So not a regression. I'm going to file a bug in the tracker for >>> that, after I get this sorted out (currently head has a bit of my hotkey >>> code already, so I want to wait until that's cleaned up before I send >>> people digging around). >>> >>> I can NOT confirm Ctrl-F, on Arch 64bit using i3. I suspect something >>> else on your system is 'eating' that keypress before kicad receives it. >>> Can you run xev and confirm whether other applications are receiving >>> that unmolested? Also, can other developers confirm whether Ctrl-F works >>> for them? >>> >>> >>> On Fri, Jan 08, 2016 at 12:58:40AM +0100, Clemens Koller wrote: >>>> Hello, Chris! >>>> >>>> FYI: changed my email address. >>>> Some more testing on Arch Linux 64bit, XFCE: >>>> >>>> An hotkey assignment <Tab> works fine, but <Ctrl>+<Tab> becomes <Ctrl>-<I> >>>> <Ctrl>-<F> doesn't get accepted at all (keypress is ignored, nothnig >>>> happens). >>>> >>>> I think I'll stop digging around that until you get the >>>> next version out. >>>> >>>> Regards, >>>> >>>> Clemens >>>> >>>> >>>> On 2016-01-07 18:30, Chris Pavlina wrote: >>>>> Thanks for the testing. >>>>> >>>>> On Thu, Jan 7, 2016 at 11:37 AM, <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hello, Chris! >>>>> >>>>> Attached is an idea/wish, how it could look like. >>>>> I hope I am not too demanding/picky... ;-) >>>>> >>>>> On 2016-01-07 15:28, Chris Pavlina wrote: >>>>> > Hey, can I get a couple more people to test the latest version of my >>>>> > hotkeys patch? Particularly someone on OS X, as I've not run into >>>>> the >>>>> > guy who usually guineapigs my stuff on OS X since finishing it... :) >>>>> > Though testing on ALL platforms is welcome. >>>>> > >>>>> > https://github.com/cpavlina/kicad/compare/options.patch >>>>> > >>>>> > Make sure setting hotkeys works for all keys, that everything looks >>>>> > halfway decent, no unexpected behavior, etc... Hotkeys can be reset >>>>> by >>>>> > right-clicking them in the list and choosing "Reset". >>>>> >>>>> Double-clicking and more popping windows to show text which could >>>>> be already there... hmmm... not my favorite. :-/ >>>>> I prefer to use spreadsheet style editing, so F2 should also edit a >>>>> field. >>>>> Put as much information in place as long as it doesn't overload the >>>>> user. >>>>> Reduce clicks as much as you can. >>>>> >>>>> >>>>> I know, but wx doesn't play nicely with other methods. Trust me, I've >>>>> tried. This seems to be a popular method for gtk applications for a >>>>> reason. >>>>> >>>>> It still works with just the keyboard, you can also press Enter to >>>>> activate the rows in the table. >>>>> >>>>> >>>>> >>>>> "Reset" Button might be named as "Reset (all?) to defaults" with >>>>> a confirmation is popping up: "Are you sure, you want to reset >>>>> all Hotkeys in current (whole tree(==all)/just current branch?) to >>>>> it's defaults?" >>>>> >>>>> >>>>> Reset doesn't reset to defaults, it resets to the value it had before the >>>>> user changed it. It's like pressing Cancel for just that item. >>>>> Unfortunately, there *is* no way to reset to defaults, as there is no >>>>> global store of defaults anywhere in KiCad. I'd like to change that, but >>>>> it'll require some more refactoring, and other things are higher in >>>>> priority right now. >>>>> >>>>> >>>>> >>>>> > The 'helper' dialog I used seems to be a fairly popular approach for >>>>> > this - it's fairly difficult to catch *any* keypress on a control >>>>> > embedded in a complex window, there's too much trying to steal >>>>> > navigation keys and whatnot. In my testing (on wxGTK and wxMSW >>>>> Win10) it >>>>> > seems quite robust. >>>>> >>>>> Can you simply avoid/hide that dialog as it doesn't ideally need to >>>>> give additional bold-face information? >>>>> >>>>> >>>>> Nope. If it's not visible and focused it doesn't get events. >>>>> >>>>> >>>>> >>>>> > Thank you all in advance. :) >>>>> >>>>> Thanks for working on this great piece of software! >>>>> >>>>> Regards, >>>>> >>>>> CKO >>>>> >>>>> On 2016-01-07 15:28, Chris Pavlina wrote: >>>>> > Hey, can I get a couple more people to test the latest version of my >>>>> > hotkeys patch? Particularly someone on OS X, as I've not run into >>>>> the >>>>> > guy who usually guineapigs my stuff on OS X since finishing it... :) >>>>> > Though testing on ALL platforms is welcome. >>>>> > >>>>> > https://github.com/cpavlina/kicad/compare/options.patch >>>>> > >>>>> > Make sure setting hotkeys works for all keys, that everything looks >>>>> > halfway decent, no unexpected behavior, etc... Hotkeys can be reset >>>>> by >>>>> > right-clicking them in the list and choosing "Reset". >>>>> > >>>>> > The 'helper' dialog I used seems to be a fairly popular approach for >>>>> > this - it's fairly difficult to catch *any* keypress on a control >>>>> > embedded in a complex window, there's too much trying to steal >>>>> > navigation keys and whatnot. In my testing (on wxGTK and wxMSW >>>>> Win10) it >>>>> > seems quite robust. >>>>> > >>>>> > Thank you all in advance. :) >>>>> > >>>>> > -- >>>>> > Chris >>>>> > >>>>> > _______________________________________________ >>>>> > Mailing list: https://launchpad.net/~kicad-developers >>>>> > Post to : [email protected] >>>>> <mailto:[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] >>>>> <mailto:[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
