kicad-developers team mailing list archive

[Ben Hest <bombledmonk@xxxxxxxxx>]

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