I can try tomorrow… > On 29 Jan 2016, at 15:44, Chris Pavlina <[email protected]> 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 : [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
