kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] new hotkeys window + some menu entry mistakes corrected + CONTRIBUTE file added
Le 03/09/2011 16:53, fabrizio a écrit :
I kind of get point. My consideration was more about a good looking
menu then 10% coherence. See in attachment how the great TextMate
does. I just think that the<> is redundant because when for instance
"B" appears next to Bus in the Place menu, that means that the "B" is
the shortcut key for the command "place bus", it is not necessary to
indicate<B>. I also think that it is important to justify all keys
right. Notice that (in my opinion) the same thing should be done in
the ohtkeys list window.
Now if commands change (or become inactive) because the mouse is
somewhere outside the sheet or whatever and the key does not work (as
I think is the case to mention), well no worries, I guess it is just
the way it is. Regardless, from an aesthetic point of view, I think we
should follow the TextMate way (which is also your way for CTRL-F for
I do not think that people will ever understand the difference between
your CTRL-F and your<B>.
This is just my opinion of course. I hope this will help.
I agree the right justified hot key is by far better than <B>.
But the difference is not for users, it is for wxWidgets event handler.
For instance, using the place bus command:
When you click on the place bus menu (or the place bus tool on right side on Eeschema),
only the place bus tool is selected.
When you click on B, the place bus tool is selected (if not already selected) and a bus is always started from the mouse cursor
Same behavior for place junction and other items.
The callback functions called by a key event is not the same callback functions called by clicking on a menu.
Unfortunately, when you create a menu with a hot key (i.e. a menu with a key right justified by a tab),
when clicking on the hot key,
the callback function called (by wxWidgets) by clicking on the key is always the menu callback function,
not the keyboard callback function.
Therefore if B is right justified (i.e. not displayed as <B>),
place bus tool is selected (as it does) but a bus is not started,
because the right callback function (keyboard function) is not called (this is the callback function relative to the menu that is
(or the hotkey J does not place a junction ...)
Unfortunately, until now, I was not able to solve safely this problem.
(Perhaps we can make the difference in menus callback functions by testing the mouse buttons state,
and expect no mouse button down when the keyboard is used, although it is not a safe way,
and this way needs changes in Kicad code)
If you know the right way (in wxWidgets) to know inside a callback function if it is called by the keyboard or by click on a menu,
the <B> notation will be safely removed ( and the Kicad internal code simplified).
On Sat, Sep 3, 2011 at 3:53 PM, jean-pierre charras
Le 03/09/2011 15:29, fabrizio a écrit :
this is my first patch, I hope it will be all right. This is what I have
2) hotkeys in the "Place" top menu are now properly displayed. They
are right justified and appear without the unnecessary "<>".
This is not possible:
As clearly written in comments in many places,
when a key appear inside "<>" this is a comment, not a hotkey equivalent to
This is due to the fact some hotkeys do not the same thing as the place menu
Therefore we cannot use always \t instead of "<>"
(It happen each time the command use the mouse position to do something, and
this is the case in place menu).
Unless someone knows, with wxWidgets,
when the same command event is generated by a hot key or by clicking on the
how we know the command event is due to a click on the hot key or click on
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