KiCad

Bug #1809929
Comment #16

Comment 16 for bug 1809929

Revision history for this message

Wayne Stambaugh (stambaughw) wrote on 2019-01-11: Re: [Bug 1809929] Re: shortcuts [shift]+[letter] doesn't work in Eeschema

#16

On 1/10/2019 4:56 PM, Seth Hillbrand wrote:
>> A hotkey is effectively a menu accelerator plus a left mouse click
> combined at the current cursor location.
>
> Got it. That's certainly different from how I've been considering
> hotkeys, so I'll have to look around a see if I've been implementing
> things counter to this thinking.
>
> Two issues come to mind when thinking about this. The first is that we
> allow hotkey definition at the moment that includes the shift key. If
> we have accelerators automatically generated that include the shift key,
> we should preclude them from being re-assigned.

Yes, unless we figure out a better key management system that allows
separate configuration of both hotkeys and accelerators. This may be
the ideal option because it will make it explicit to users that each key
combination is distinct.

>
> The second is that, in our hotkeys editor, the pcbnew tools are really
> accelerators in that we don't have a key that activates a tool _and_
> places a via or starts a track, etc. We do have "drag track" and
> "insert point" but I think those might be the only ones that perform
> this way.

Some of this stems from the differences between the legacy and modern
tool frameworks. We were probably a bit lax with the new tool framework
behavior in regards to hotkey versus accelerator which only added to the
confusion. There is definitely some work remaining to be done.

>
> Notably, adding a component, track or graphic item in pcbnew is press
> key + click while in eeschema, it is press key only. Both actions are
> controlled by the key assigned in the "hotkey editor", so we should
> expect that users will only refer to hotkeys.
>

This should be fixed to behave the same was as the legacy tool
framework. The whole point of hotkeys is to reduce the number of
actions required to begin performing a task. Even though the new tool
framework has a lot more gee whiz features, I still prefer the behavior
of the legacy tool framework for getting work done. Once the legacy
tool framework is gone, I'm going to draw a much harder line on getting
this correct.

On 1/10/2019 4:56 PM, Seth Hillbrand wrote:
>> A hotkey is effectively a menu accelerator plus a left mouse click
> combined at the current cursor location.
> 
> Got it.  That's certainly different from how I've been considering
> hotkeys, so I'll have to look around a see if I've been implementing
> things counter to this thinking.
> 
> Two issues come to mind when thinking about this.  The first is that we
> allow hotkey definition at the moment that includes the shift key.  If
> we have accelerators automatically generated that include the shift key,
> we should preclude them from being re-assigned.

Yes, unless we figure out a better key management system that allows
separate configuration of both hotkeys and accelerators.  This may be
the ideal option because it will make it explicit to users that each key
combination is distinct.

> 
> The second is that, in our hotkeys editor, the pcbnew tools are really
> accelerators in that we don't have a key that activates a tool _and_
> places a via or starts a track, etc.  We do have "drag track" and
> "insert point" but I think those might be the only ones that perform
> this way.

Some of this stems from the differences between the legacy and modern
tool frameworks.  We were probably a bit lax with the new tool framework
behavior in regards to hotkey versus accelerator which only added to the
confusion.  There is definitely some work remaining to be done.

> 
> Notably, adding a component, track or graphic item in pcbnew is press
> key + click while in eeschema, it is press key only.  Both actions are
> controlled by the key assigned in the "hotkey editor", so we should
> expect that users will only refer to hotkeys.
>

This should be fixed to behave the same was as the legacy tool
framework.  The whole point of hotkeys is to reduce the number of
actions required to begin performing a task.  Even though the new tool
framework has a lot more gee whiz features, I still prefer the behavior
of the legacy tool framework for getting work done.  Once the legacy
tool framework is gone, I'm going to draw a much harder line on getting
this correct.