kicad-developers team mailing list archive

[Jeff Young <jeff@xxxxxxxxx>]

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>
>>> <mailto:john.j.beard@xxxxxxxxx <mailto: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 <https://launchpad.net/~kicad-developers>
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>