I also think command palettes are great, and one of the things I want to explore in the future in comparison to chained hotkeys as a way of getting past the restrictive nature of our current hotkey system.
I think this is mostly irrelevant to the change Jeff proposes -- in the new proposed architecture, it will be possible to enumerate all the commands and list them in a palette just as easily as linking hotkeys to them, I think. -Jon On Fri, May 10, 2019 at 3:05 PM Ben Hest <[email protected]> wrote: > I apologize if this is diverging from the subject too much, but it, at > least, has the potential to be pertinent to an architecture underlying this > topic. I'm finding more programs emplying the powerful concept of command > pallets[1] and find the idea to be very appealing for a program like KiCad. > A few positives of command pallets: > > They allow for discoverability/findability so you don't have to know > exactly which dialog or menu a setting/preference/action is in. (see > sublime, vs code, atom)[2] > They allow for hotkey discovery. > [image: sublime_command_pallet.png] > They allow for aliasing names of settings/preferences/actions (see excel) > [3] > [image: image.png] > > > [1] > https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette > [2]https://hest.pro/images/kicad/sublime_command_pallet.png > [3]https://hest.pro/images/kicad/excel_commands.png > > > > On Fri, May 10, 2019 at 9:53 AM Jon Evans <[email protected]> wrote: > >> Wayne is referring to chained (sequential) hotkeys that I discussed with >> the group at KiCon (this has also been requested on the tracker[1]) >> >> I think that the architecture you proposed could support this too. We >> haven't yet gotten in to any thinking about exactly how the architecture >> for chained hotkeys would work, but it seems to me like it would fit into >> the map system you propose, because ultimately it is just a more advanced >> case of context-sensitive hotkeys (each chain starts with a global hotkey >> and then a sequence of context-sensitive hotkeys that operate in the >> context of the previous hotkey) >> >> -Jon >> >> [1] https://bugs.launchpad.net/kicad/+bug/1616154 and I think some other >> instances in the past >> >> On Fri, May 10, 2019 at 10:37 AM Jeff Young <[email protected]> wrote: >> >>> 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] <[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 >>> 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 >> > > > -- > > -Ben >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
