Hi Wayne, That’s right; this proposal was just supposed to be about architecture, not features.
However, it does need to support new features. I don’t think there’s an issue with immediate vs. select-tool. As for chaining, you’re really chaining actions, not hotkeys, right? So either proposal (no maps vs. single map) could support chaining. Cheers, Jeff. > On 10 May 2019, at 14:12, Wayne Stambaugh <[email protected]> wrote: > > Jeff, > > You proposal doesn't seem to meet the objectives we discussed about > allowing the user to chose the hotkey behavior for actions that can > perform an action at the current cursor position but maybe I'm missing > something. Also, don't forget about Jon's proposal for chained key > combinations. I imagine you will need some type of data structure to > accommodate both of these so removing the hotkey data structures may not > be the best path forward. I do agree that our hotkey code needs a major > overhaul. > > Cheers, > > Wayne > > On 5/10/19 8:00 AM, Jeff Young wrote: >> It’s worth pointing out that either scheme also has the huge advantage >> that a hotkey can be assigned to /any/ Action (and going forward, that >> will be pretty much everything we do). >> >>> On 10 May 2019, at 12:15, John Beard <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>> On 10/05/2019 11:53, Jeff Young wrote: >>>> My concern with this is that the more spread out you store the info, >>>> the more maps you need, and the more room for error you have (when >>>> maps are missing keys, etc.). >>> >>> I have a single big default list in mind, rather than many disparate >>> lists. This is constructed as suitable for the platform (e.g. macOS >>> defaults when needed).[1] >>> >>> It's OK for actions to be missing bindings. I think quite few >>> TOOL_ACTIONs would be OK with a empty-by-default hotkey. For example, >>> there are 10 layer-visibility presets in the Layer panel context menu >>> with no hotkeys at all - these don't all need defaults, but it would >>> be good to be able to set them if users want. >>> >>> Loading duplicate (default) keys could be an assert (cos it's >>> user-unfriendly to ship it like that) followed by one of skip or >>> remove existing. That would just result in a missing hotkey binding at >>> load. Ditto for loading strings that don't exist (tool removed/changed >>> ID). It's not fatal, the worst outcome is a missing binding that the >>> user can set. >>> >>> Cheers, >>> >>> John >>> >>> [1]: *Maybe* this would also be the right place for locale-specific >>> hotkeys munging too? E.g. if Cyrillic keyboards, say, don't work well >>> with the Latin defaults. >> >> >> _______________________________________________ >> 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 > <https://launchpad.net/~kicad-developers> > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > <https://launchpad.net/~kicad-developers> > More help : https://help.launchpad.net/ListHelp > <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
