kicad-developers team mailing list archive

[Clemens Koller <cko@xxxxxxxxx>]

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, <cullinan@xxxxxxxxxxxxxx <mailto:cullinan@xxxxxxxxxxxxxx>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto: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 <mailto: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