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
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.
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.
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
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
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
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
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
> 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.
>
>
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,
10 matches
Mail list logo
