kicad-developers team mailing list archive
Mailing list archive
Re: 6.0 action-based hotkeys proposal
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.
> 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.
>> 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.
>> +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.
>> 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