kicad-developers team mailing list archive
Mailing list archive
Re: 6.0 task proposal
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.
> On 10 May 2019, at 14:12, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 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
> 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).
>>> 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.
>>> : *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>