kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 08/11/2014 10:44, Nick Østergaard a écrit :
> 2014-11-08 10:32 GMT+01:00 jp charras <jp.charras@xxxxxxxxxx>:
>> Le 07/11/2014 23:24, Nick Østergaard a écrit :
>>> Hello
>>>
>>> The attached patch makes the shortcut text label for the "Place ->
>>> Track" menu option show the hotkey as it is done in every other menu.
>>> Before it showed for example "Place (X)" instead of
>>> "Place<whitespace>X", where the hotkey is right aligned in the second
>>> case.
>>
>> They are not equivalent.
>> - hotkey X  switches the current tool to "place track mode" and starts
>> a track from the cursor position (therefore the cursor is expected to be
>> on the right location)
>> - click on menu switch the current tool to "place track mode", but does
>> not start a track
> 
> Ok, I can see that behaivour, and I think that makes sense. But I can
> not understand why the menu entry should show its hotkey in a
> different way than everything else.

For this menu, this is not a hotkey.
when the menu is displayed like "Place<tab>X", X becomes a hotkey.
This is managed by wxWidgets, not Kicad.
You cannot choose how the menu is displayed.

> 
>> This is the reason one cannot use "Place<tab>X" instead of "Place (X)"
>> (there are other places in menus where the case happens: in zoom menu
>> for instance)
> 
> In the View > Zoom In/Out the is written with "View In<tab>Alt+F1" and
> the actions work differently. When clicking the menu it will zoom in
> on the center using the hotkey it will zoom in at the cursor.

There are 2 hotkeys for zoom: one for the menu, the other outside the menu.
But we have a limited number of keys, and therefore we cannot use 2 keys
for each menu, only for the most important commands.

> 
>> (I never found a reliable and easy way to know if a menu event was
>> created by clicking on a menu, or from its hotkey)
> 
> So the way it is done now is actually a workaround to distinguish them?
> 

Yes.

-- 
Jean-Pierre CHARRAS