kicad-developers team mailing list archive
Mailing list archive
Re: Need testers for a patch to merge hotkeys and accelerators
I’m testing the V2 patch on OS X now. I made sure the hotkeys were set back to their defaults in the preferences before testing.
Unfortunately, pressing a hotkey just triggers the accelerator action, and not the hotkey. Same thing in eeschema as well as GAL and Legacy canvases.
Oddly, in GAL and Legacy canvases, when the Track tool is already the current tool, pressing Ctrl+X will trigger the hotkey and a new track will begin from the mouse position. There is one difference I see between GAL and Legacy: In GAL if the Track tool is not current, Ctrl+X does *not* trigger the hotkey. But in Legacy, regardless of what tool is current, Ctrl+X calls the hotkey and starts a new track immediately.
Eeschema’s hotkeys behave the same as pcbnew Legacy: for example W will always call the accelerator. Like pcbnew legacy canvas, Ctrl+W will call the hotkey.
By ‘Ctrl’ I mean the OS X Control key, i.e. WXK_RAW_CONTROL
As far as the python scripting console, I’m not sure what to be testing here. All keys, including ‘O’ and ‘X’, show up in the console window when I type.
Hope that helps. Thanks,
On Wednesday, October 4, 2017 at 5:10 AM, jp charras wrote:
> Le 03/10/2017 à 21:01, jp charras a écrit :
> > Hi All,
> > Currently, when a key is used as hotkey and if we want to display it in a sub-menu of the main menu,
> > because it becomes a accelerator key, we need to modify it (adding shift or alt modifier) when the
> > action differs (uses the mouse position) when called from a menu or a key.
> > Although there are not a lot of cases (zoom in and out are 2 cases, and there are more cases in
> > Eeschema), this is annoying for 2 reasons:
> > - Many users do not know the difference between a accelerator key and a hotkey.
> > - 2 similar actions use 2 keys instead of only one key, and we do not have a lot of available keys
> > for hotkeys, so wasting a few keys is very annoying.
> > I wrote a patch to use the same key as accelerator key and hotkey.
> > In fact, if a menu uses (for a accelerator key) the same key as a hotkey, the key event is not sent
> > to this menu, and the "accelerator key" becomes just a comment in menu.
> > To do that, the EVT_CHAR_HOOK key event is now managed by the main frame and is filtered, and not
> > sent to the GUI if a hotkey handles this key event (this is the normal way to handle keys whenn we
> > have special requirements).
> > Unfortunately, the way EVT_CHAR_HOOK and EVT_CHAR key events are exactly working is highly dependent
> > of platforms, and a bit tricky.
> > I tested this patch on Windows 32 bits, and partially on Linux (I was not able to test the python
> > console), but not on OSX.
> > Obviously, it must be tested (both in legacy canvas and GEL canvas) on OSX, and Linux (and of course
> > on Windows 64 bits), and especially with Pcbnew in python console:
> > are all chars captured in the console, especially the 2 accelerators 'O' and 'X'
> > Thanks.
> I fixed some issues found in my first patch.
> I also tested the wxpython console both on Windows and Linux.
> I fixed an issue on Linux, and the python console works now.
> So tests on OSX are now needed.
> Jean-Pierre CHARRAS
> 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
> - merge_hotkeys_and_accelerators_V2.patch