kicad-developers team mailing list archive

[Jerry Jacobs <xor.gate.engineering@xxxxxxxxx>]

On 4/4/11 9:41 PM, jean-pierre charras wrote:
> Jerry,
> Your last change in rev 2945 in file:
> common/hotkeys_basic.cpp
> breaks Kicad.
>
> The reason is when a key is added in a menu, with a \t before it, it
> become a shortcut.
> Therefore type is key is exactly equivalent to click on this menu, and
> this key is no more sent to the kicad key handler..

I don't know for sure, but for me on OS X all the Placement hotkeys 
which I tested (in EESchema) works as expected. With wxWidgets 2.9.2 
svn. And don't break the hotkey internals, correct me if I'm wrong.

> This break Kicad, because many hotkeys does not the same thing as you
> are click on menus.
> Mainly because hot keys use current mouse cursor position (start a wire,
> zoom, ...)
> and obviously this is not possible when clicking on a menu.
> This is true for menus in frame menu bar, not pop up menus, because they
> are not active.
> So in many cases keys added in menus in the menu bar are only comments,
> not shortcuts.

This "bad" comments "break" the Mac UI policy and are a bit ugly 
compared to the defaults.

> Please, unless you known (with wxWidgets) how to see the difference
> between click on a menu
> and click on the corresponding hotkey,
> (I do not know how to do that, and if this is possible, because the same
> event is sent,
> perhaps try to use wxEvent::GetEventType() to do that, but this needs a
> lot of changes),
> go back to the previous version of common/hotkeys_basic.cpp.
> Aesthetic reason to this change is not a good reason, if this change
> breaks the previous behavior.
> Currently, most of hotkeys are not working properly.

It is no problem to revert back to the previous version of this file.