kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

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.chris@xxxxxxxxx> 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 <stegmaier@xxxxxxxxxxxxx> wrote:
>>> 
>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> 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
>>