Re: [Kicad-developers] 6.0 task proposal

[Jon Evans]

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  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  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  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  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 >> > 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.
>>>

Re: [Kicad-developers] 6.0 task proposal

[Ben Hest]

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  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  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  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 > > 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@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> ___
>> Mailing 

Re: [Kicad-developers] 6.0 task proposal

[Tomasz Wlostowski]

On 10/05/2019 11:46, John Beard wrote:
> Do the tool actions actually even need to know their hotkey? I think
> perhaps they shouldn't really care *what* the hotkey is or even if one
> is set, it's not their problem. It's the tool framework that should be
> maintaining this mapping.

Hi,

+1 here. The hotkeys (standard, sequential and
whatever-else-we-come-up-with) can be kept separate from the ACTION
objets in the code and stored in a configuration file. This would let
people coming from other EDA packages to have their own config files
with custom hotkey mappings.

IMO the same approach later can be used for toolbar/menu layouts.

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 task proposal

[Jon Evans]

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  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  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  > 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 task proposal

[Jeff Young]

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  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 >> 
>>> >> 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@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 task proposal

[Wayne Stambaugh]

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 > > 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@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 task proposal

[Jeff Young]

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  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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 task proposal

[John Beard]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 task proposal

[Jeff Young]

> On 10 May 2019, at 11:46, John Beard  wrote:
> 
> On 10/05/2019 11:08, Jeff Young wrote:
>> Once we remove PCBNew’s legacy canvas I’d like to propose that we simplify 
>> the hotkey architecture:
>> Get rid of the HotKey data-structures; have Actions specify a hotkey 
>> key-combination.
> 
> +0 (strongly support stripping legacy hotkey infrastructure, but...)
> 
> Do the tool actions actually even need to know their hotkey? I think perhaps 
> they shouldn't really care *what* the hotkey is or even if one is set, it's 
> not their problem. It's the tool framework that should be maintaining this 
> mapping.
> 
> Tools have a unique handle, the tool framework is in charge of invoking the 
> tool as needed. It's like a hammer doesn't come with a label saying how to 
> find it, it's up to you to put it in the right drawer and remember where it 
> is.

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.).

That being said, certainly 1 map (hotkey to action) is better than the 3 we 
have today (hotkey to legacyID, legacyID to action, and hotkey to category).

> 
>> Down-side:
>> 1) You won’t be able to see all the key-combinations in one place in the 
>> code (but you can run Kicad to see them together).
> 
> Is there a way to load in a default action-string->hotkey mapping? So the 
> TOOL_ACTIONs have a slot for the hotkey as currently, but it's empty/0 at 
> static init. Then load that with a (e.g.) std::unordered_map int> for the defaults.

If we did have a single map (see above), then yes, this is how I’d see it 
working too.  (It doesn’t exist today, but we could write it.)

Cheers,
Jeff.

> 
> There should be an interface layer (i.e. a hotkey config model) mediating the 
> tool framework, the config file and the hotkey dialog anyway, so this is just 
> a function of that that can be called at startup.
> 
> Then it might be easier to see conflicts, which are otherwise tricky to find, 
> especially when platforms (looking at you, macOS) have different default 
> hotkeys.
> 
> Cheers,
> 
> John
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 task proposal

[John Beard]

On 10/05/2019 11:08, Jeff Young wrote:

Once we remove PCBNew’s legacy canvas I’d like to propose that we simplify the 
hotkey architecture:

Get rid of the HotKey data-structures; have Actions specify a hotkey 
key-combination.


+0 (strongly support stripping legacy hotkey infrastructure, but...)

Do the tool actions actually even need to know their hotkey? I think 
perhaps they shouldn't really care *what* the hotkey is or even if one 
is set, it's not their problem. It's the tool framework that should be 
maintaining this mapping.


Tools have a unique handle, the tool framework is in charge of invoking 
the tool as needed. It's like a hammer doesn't come with a label saying 
how to find it, it's up to you to put it in the right drawer and 
remember where it is.



Down-side:
1) You won’t be able to see all the key-combinations in one place in the code 
(but you can run Kicad to see them together).


Is there a way to load in a default action-string->hotkey mapping? So 
the TOOL_ACTIONs have a slot for the hotkey as currently, but it's 
empty/0 at static init. Then load that with a (e.g.) 
std::unordered_map for the defaults.


There should be an interface layer (i.e. a hotkey config model) 
mediating the tool framework, the config file and the hotkey dialog 
anyway, so this is just a function of that that can be called at startup.


Then it might be easier to see conflicts, which are otherwise tricky to 
find, especially when platforms (looking at you, macOS) have different 
default hotkeys.


Cheers,

John

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp