No problem, you are welcome. I forgot to test: Ctrl-xx and Alt-xx also don’t seem to do anything when trying to configure it as a hotkey in a version before you started to change things (tested with 6397). So, no regression with those… :)
> On 30.01.2016, at 16:48, Chris Pavlina <pavlina.ch...@gmail.com> wrote: > > Thank you very much! > > Nah, nothing else yet - I'll try to get these fixed first. I figured Ctrl-xx > would be the normal issue with Ctrl vs Command on OSX, but Alt? hrm. I may > have > to see if I can find an OSX machine to borrow for a while. > > On Sat, Jan 30, 2016 at 11:27:09AM +0100, Bernhard Stegmaier wrote: >> I played around a bit: >> * Normal keys without modifier seem to be fine >> * I can confirm the space/bell issue. This is not the case with the rev 6493 >> I am currently working with, so this seems to be a regression. >> * Special keys like Tab, PgUp, etc. seem to be OK >> * Cmd-xx seems to work with xx being some normal key, e.g. Cmd-b or even >> Cmd-Shift-B. Some seem to be catched directly by OS X (e.g., Cmd-Tab) or >> don’t do anything (e.g., Cmd-Return). >> * Ctrl-xx or Alt-xx don’t work with xx being any normal key I tried. The >> hotkey change window gets closed, but no hotkey is assigned. >> >> Any other special case to test? >> >> >> Regards, >> Bernhard >> >> >>> On 29.01.2016, at 18:34, Bernhard Stegmaier <stegma...@sw-systems.de> wrote: >>> >>> I can try tomorrow… >>> >>>> On 29 Jan 2016, at 15:44, Chris Pavlina <pavlina.ch...@gmail.com> wrote: >>>> >>>> Have any OS X devs had a chance to test this? I got a test from one, but >>>> haven't been able to track down a followup to a potential regression. >>>> >>>> I have a report that using <space> as a hotkey on OSX with this patch >>>> causes a >>>> bell. Does someone have a chance to check that for me? Most importantly >>>> right >>>> now, check whether that happens on an unpatched build - i.e., whether it >>>> is a >>>> regression. >>>> >>>> On Fri, Jan 22, 2016 at 04:04:44PM -0500, Chris Pavlina wrote: >>>>> Updated patch - quite a few changes. First I noticed I was inadvertently >>>>> trapping some keys I shouldn't (try using Ctrl+S with the original >>>>> patch...), and then I decided to tackle the old "bug" that certain key >>>>> combinations, like Shift+Tab, cannot be used. >>>>> >>>>> To make sure hotkeys are recognized equally everywhere, I took the code >>>>> I originally wrote for the hotkey editor widget to handle wxEVT_CHAR and >>>>> wxEVT_CHAR_HOOK keypress events "intelligently" and factored it out into >>>>> a separate class to be used in other places. I then pulled it into >>>>> EDA_DRAW_PANEL and EDA_DRAW_PANEL_GAL to replace the existing keycode >>>>> rewriting code (which originally was just "if hotkey is in WXK_CONTROL_A >>>>> through WXK_CONTROL_Z, remap to Ctrl + A..Z"). >>>>> >>>>> With this patch, all 'standard' combinations of keys on a US keyboard >>>>> should be usable, support for international keys is the same as before. >>>>> Let me know if you find any combinations that don't work. >>>>> >>>>> Please test! This is platform-dependent stuff - it's the same >>>>> platform-dependent stuff as before, but I need to make sure I haven't >>>>> added regressions. I've tested on Linux and Win10; more thorough testing >>>>> even on those same platforms is welcome. >>>>> >>>>> >>>>> On Wed, Jan 20, 2016 at 10:44:36PM -0500, Chris Pavlina wrote: >>>>>> There is an old bug that people turned up while testing my new hotkey >>>>>> editor, attached is a patch that fixes it. This patch pokes into the >>>>>> main hotkey handling code, so I really want as many people to test it as >>>>>> possible - it's a relatively minor bug, I don't want to go introducing >>>>>> twelve regressions to fix one small bug. Here's what I want to keep an >>>>>> eye out for: >>>>>> >>>>>> - Hotkeys (Ctrl+Tab), (Tab), and (Ctrl+I) are all independent and >>>>>> distinguished from each other, both in the hotkey editor and in actual >>>>>> use. Make sure all of them work, and make sure none of them answers >>>>>> for the others. >>>>>> >>>>>> - Hotkeys that are *not* handled by the main hotkey code (for example, >>>>>> menu keys like Alt+F to call up the File menu) are not affected. >>>>>> >>>>>> - Behavior on OSX, with its weird Ctrl mapping, is not broken (or, at >>>>>> least, is no more broken than usual ;) >>>>>> >>>>>> I have tested on Linux and Windows 10, though more thorough testing on >>>>>> those platforms is welcome. >>>>>> >>>>>> Patch/bug summary: >>>>>> >>>>>> [PATCH] Fix (Ctrl)+(ASCII control key) hotkey handling >>>>>> >>>>>> wxWidgets has quirks with how it handles these keys. For example, in >>>>>> wxEVT_CHAR, Ctrl+Tab and Ctrl+I are indistinguishable. >>>>>> >>>>>> - Modify the special wxEVT_CHAR_HOOK handler from WIDGET_HOTKEY_LIST to >>>>>> handle this case as well as the other funny cases it already handles. >>>>>> >>>>>> - Factor this handler out into a function in hotkeys_basic.h for use >>>>>> elsewhere. >>>>>> >>>>>> - Add this handler to the central hotkey handler, remove existing >>>>>> (buggy) ASCII control key handling. >>>>>> >>>>>> Thanks for testing. >>>>>> >>>>>> -- Chris >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : kicad-developers@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
