kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

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 <bombledmonk@xxxxxxxxx> 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 <jon@xxxxxxxxxxxxx> 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 <jeff@xxxxxxxxx> 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 <stambaughw@xxxxxxxxx> 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 <john.j.beard@xxxxxxxxx
>>> <mailto:john.j.beard@xxxxxxxxx <john.j.beard@xxxxxxxxx>>> 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     : 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> --
>
> -Ben
>