kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

Just an update here:

The compromise didn’t turn out to be one after all.  I had always assumed TOOL_ACTION::LegacyHotKey( HK_RESET_LOCAL_COORD ) looked up the hotkey’s ID and stored it in the action, but it doesn’t: it looks up and stores the key-combination.  So the proposal: "The default hotkey key-combinations are defined in the TOOL_ACTION constructors." is already how it works.

That means I can put the mapping stuff on the long finger.  I’ll still be able to get rid of the wxIDs and all their associated mappings.

With one caveat: the toolbars are still using the wxIDs.  So we also need an ACTION_TOOLBAR.  (Which will also remove yet another copy of duplicated UI strings when instantiating toolbar buttons.)

I thought about a CONDITIONAL_TOOLBAR as well which would use the conditions to set the tool highlighting, but I think that’s probably overkill.  We already have SyncMenusAndToolbars() which updates their highlighting.

Cheers,
Jeff.


> On 12 May 2019, at 20:42, Jeff Young <jeff@xxxxxxxxx> wrote:
> 
> OK, how about a compromise:
> 
> The default hotkey key-combinations are defined in the TOOL_ACTION constructors.
> 
> A config file is then read which contain maps from action-name to key-combinations.  Each map entry is applied to its action, overwriting the default.
> 
> This also allows us to skip yet-ever-more-config-options: if the user wants immediate actions then they can import the immediate-action-mappings config file.  The default will be the (somewhat more learner-friendly) select-tool-mappings.
> 
> Similarly, as Tom suggests they could import the Altium-mappings config file.
> 
> For Tom’s last paragraph, I plan to rename CONTEXT_MENU to ACTION_MENU.  CONDITIONAL_MENUs constructor then takes a isContextMenu flag; if it’s not set then conditions which evaluate to false produce disabled menu items (rather than non-existant menu items).
> 
> We can then plug these menus into the main menu bar and get rid of the wx-based IDs altogether (and all the corresponding EVT_MENU and EVT_UPDATE_UI calls).  Actions will get dispatched automatically by TOOL_DISPATCHER, and the enabling/disabling will get handled automatically by the CONDITIONs.
> 
> Comments?
> 
> Cheers,
> Jeff
> 
> 
>> On 10 May 2019, at 16:01, Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx> wrote:
>> 
>> On 10/05/2019 11:46, John Beard wrote:
>>> Do the tool actions actually even need to know their hotkey? I think
>>> perhaps they shouldn't really care *what* the hotkey is or even if one
>>> is set, it's not their problem. It's the tool framework that should be
>>> maintaining this mapping.
>> 
>> Hi,
>> 
>> +1 here. The hotkeys (standard, sequential and
>> whatever-else-we-come-up-with) can be kept separate from the ACTION
>> objets in the code and stored in a configuration file. This would let
>> people coming from other EDA packages to have their own config files
>> with custom hotkey mappings.
>> 
>> IMO the same approach later can be used for toolbar/menu layouts.
>> 
>> Cheers,
>> Tom
>> 
>> _______________________________________________
>> 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