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 <[email protected]> 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 <[email protected]> >> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
