kicad-developers team mailing list archive

[John Beard <john.j.beard@xxxxxxxxx>]

On 10/05/2019 11:08, Jeff Young wrote:
> Once we remove PCBNew’s legacy canvas I’d like to propose that we simplify the hotkey architecture:
>
> Get rid of the HotKey data-structures; have Actions specify a hotkey key-combination.

+0 (strongly support stripping legacy hotkey infrastructure, but...)

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.

Tools have a unique handle, the tool framework is in charge of invoking 
the tool as needed. It's like a hammer doesn't come with a label saying 
how to find it, it's up to you to put it in the right drawer and 
remember where it is.

> Down-side:
> 1) You won’t be able to see all the key-combinations in one place in the code (but you can run Kicad to see them together).

Is there a way to load in a default action-string->hotkey mapping? So 
the TOOL_ACTIONs have a slot for the hotkey as currently, but it's 
empty/0 at static init. Then load that with a (e.g.) 
std::unordered_map<std::string, int> for the defaults.

There should be an interface layer (i.e. a hotkey config model) 
mediating the tool framework, the config file and the hotkey dialog 
anyway, so this is just a function of that that can be called at startup.

Then it might be easier to see conflicts, which are otherwise tricky to 
find, especially when platforms (looking at you, macOS) have different 
default hotkeys.

Cheers,

John