kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

I can try tomorrow…

> On 29 Jan 2016, at 15:44, Chris Pavlina <pavlina.chris@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp