shortcuts [shift]+[letter] doesn't work in Eeschema

[tijuca]

A bug report against the Debian BTS was recently opened because the reporter has noticed that shortcuts in Eeschema with the shift key in the combination doesn't work in 5.0.1 and later also in 5.0.2. I see this too in the current HEAD.

Application: kicad
Version: (6.0.0-rc1-dev-1053-gc05ca469a-dirty), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.62.0 OpenSSL/1.1.1a zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.35.1 librtmp/2.3
Platform: Linux 4.18.0-3-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.62.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.0
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=ON
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

I'm working with Gnome3 3.30.1 and gdm3 as window manager and X11 on Debian testing. The original bug reporter stated he is using Stretch's XFCE with xfwm4 version 4.12.4.

https://bugs.debian.org/916461

Someone can confirm this?

Regards
Carsten

[Dmitriy Sentishchev (ds.flyingcat)]

It seems that the problem only in displaying shortcuts in the menu.
Shortcuts in Preferences->Preferences...->Hotkeys displays as only [letter] without [shift] and work fine.
In my opinion, the lack of need to press shift is better.

Regards
Dmitriy

[tijuca (c-schoenert)]

I personally can live fine with just the [letter] as hotkey. But no matter what behavior is (still) intended here there is some inconsistency between the menus and the help display then.

Regards
Carsten

[jean-pierre charras (jp-charras)]

Shift + letter works fine.

Menus show accelerator keys, not shortcuts.
Accelerator keys activate the corresponding tool and are equivalent to click on the sub-menu.

Shortcuts have a different behavior.

For instance Shift+W activate the Place wire tool.
W starts a wire at the cursor location, and this action cannot made when clicking on the sub-menu, because the cursor location cannot be used as start point.

[tijuca (c-schoenert)]

Well, I'm aware that hotkeys something different than shortcuts.

The point is simply that the menu 'Place' in Eeschema shows 'Shift+A' for inserting a symbol, the list of hotkeys (by Help->List Hotkeys...") shows 'A' instead without 'Shift' correctly then for adding a symbol. And this is a inconsistency for me.

[Wayne Stambaugh (stambaughw)]

@JP, did you test using gtk3? I did some quick testing and the Shift menu accelerator keys do not appear to be working for me. I don't see the correct tool being enabled. I seem to remember this working with gtk2. Would one of the developers using a gtk3 build please confirm this?

[Seth Hillbrand (sethh)]

Shift+Key works as expected in pcbnew. Does not work in Eeschema. In Eeschema, the same key works without the "Shift" modifier

[jean-pierre charras (jp-charras)]

After tests:
This issue is Linux specific (works fine on W7):
Shift+letter does not work both using GTK2 and GTK2 on my installs (KDE and Unity)

[Seth Hillbrand (sethh)]

Application: kicad
Version: (6.0.0-rc1-dev-1505-gd1b53028a1-dirty), release build
Libraries:
    wxWidgets 3.0.4
Platform: Linux 4.18.0-3-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
    Boost: 1.67.0
    OpenCASCADE Community Edition: 6.9.1
    Compiler: GCC 8.2.0 with C++ ABI 1013

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=OFF
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Wayne Stambaugh (stambaughw)]

I believe the reason this works in with the new tool framework is that the menu accelerators have a Ctrl+ prefixed. At least this is what I remember seeing when I was testing. This would explain why it works in pcbnew and not in eeschema. I'm at work so I cannot confirm this.

[Seth Hillbrand (sethh)]

Hmm... In more detail, re-assigning the menu accelerator for the line tool to Shift+L in pcbnew and testing. It works as expected.

In Eeschema, the menu accelerators show Shift+letter but in the hotkey list, they are only the capital letter. Assigning the hotkey in Eeschema to Shift+letter causes the accelerator to behave correctly. The menu display does not change.

I suspect that this is only a menu display issue

[Wayne Stambaugh (stambaughw)]

On 1/9/19 1:46 PM, Seth Hillbrand wrote:
> Hmm... In more detail, re-assigning the menu accelerator for the line
> tool to Shift+L in pcbnew and testing. It works as expected.
>
> In Eeschema, the menu accelerators show Shift+letter but in the hotkey
> list, they are only the capital letter. Assigning the hotkey in
> Eeschema to Shift+letter causes the accelerator to behave correctly.
> The menu display does not change.

I think your confusing hot keys and menu accelerators here. Menu
accelerators are merely a shortcut to selecting a menu entry with the
mouse. Using the menus entries work as expected.

>
> I suspect that this is only a menu display issue
>

[tijuca (c-schoenert)]

Hello Wayne,

Am 09.01.19 um 23:40 schrieb Wayne Stambaugh:
> On 1/9/19 1:46 PM, Seth Hillbrand wrote:
>> Hmm... In more detail, re-assigning the menu accelerator for the line
>> tool to Shift+L in pcbnew and testing. It works as expected.
>>
>> In Eeschema, the menu accelerators show Shift+letter but in the hotkey
>> list, they are only the capital letter. Assigning the hotkey in
>> Eeschema to Shift+letter causes the accelerator to behave correctly.
>> The menu display does not change.
>
> I think your confusing hot keys and menu accelerators here. Menu
> accelerators are merely a shortcut to selecting a menu entry with the
> mouse. Using the menus entries work as expected.

I'm sure have not understand all things and methods within KiCad so
sorry if I've used some wrong wording and produced some confusing. :)

Seth last answer to the report seem to exactly describing the problem
that is happen (and what I wanted to describe).

--
Regards
Carsten Schoenert

[Seth Hillbrand (sethh)]

I guess that we should decide what we show in the menus. Eeschema shows the accelerators and pcbnew shows the hotkeys.

I would suggestion that we could reduce confusion by removing the menu accelerators altogether and only listing hotkeys in the menus.

[Wayne Stambaugh (stambaughw)]

On 1/10/2019 1:59 PM, Seth Hillbrand wrote:
> I guess that we should decide what we show in the menus. Eeschema shows
> the accelerators and pcbnew shows the hotkeys.

Accelerators should be shown in menus because they are not hotkeys. You
cannot start drawing a wire, bus, symbol, etc by selecting menu. The
cursor location when selecting a menu entry has no meaning. The menu
accelerator should have the same effect as selecting a menu entry or
clicking on the equivalent toolbar button which merely enables a tool so
that the next time the mouse is left clicked on the canvas, the selected
tool action begins. A hotkey is effectively a menu accelerator plus a
left mouse click combined at the current cursor location.

In the past, menu accelerators were generated at run time by prefixing
Shift+ to the hotkey which should always be a single character for ease
of use. I'm not sure what is going on now but something is amiss if
this is no longer the case.

>
> I would suggestion that we could reduce confusion by removing the menu
> accelerators altogether and only listing hotkeys in the menus.
>

I am having a hard time understanding why we have such difficulty
distinguishing between the two concepts. Maybe users like having to
perform multiple keyboard and/or mouse operations to start a task.

[Seth Hillbrand (sethh)]

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

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.

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.

[Wayne Stambaugh (stambaughw)]

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.

[Wayne Stambaugh (stambaughw)]

I think we should fix this during v6. Once the legacy canvas code is removed from the source tree, the hotkey and menu accelerator code should be simplified since we will only have the new toolkit to deal with. There are some subtle key handling differences between platforms so I don't think this bug will be as trivial to fix as it would appear.

[Jeff Young (jeyjey)]

@Wayne, is the 6.0 hotkeys architecture sufficient to close this bug, or is there still work to be done?

[Wayne Stambaugh (stambaughw)]

@Jeff, I closed this out since the v6 changes have changed the hotkey behavior. We'll see whether or not users prefer both the immediate and non-immediate modes combined in v5 or the either or mode of v6. That would be a different bug report.

[Aleksandr Sh (dsa-t)]

Through this may be fixed in 6.0, it is still present in 5.1, leading to confusion for Linux users, especially the ones coming from Windows and having used Shift+[key].

I think there are two ways to reduce user confusion:

1. Make "menu accelerators" in eeschema work on Linux
2. Remove them from the menus on Linux

Application: Eeschema
Version: 5.1.4-br-unknown-fb565ca~84~ubuntu18.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-20-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Curl: 7.58.0
Compiler: GCC 7.4.0 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=ON
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON

$ lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description: Linux Mint 19.1 Tessa
Release: 19.1
Codename: tessa

[Mike Reed (dunaden)]

Just found this thread as I am a Linux Mint user testing out migrating to Kicad from Altium/Eagle.

I just want to double check that there is currently no way to use the accelerator key functions (ie. pressing some keyboard combination to activate the "Place Wire" tool but not run the hotkey "Start Wire" command) on Linux.

I don't really care so much if I need to map them to another key combination that works, I just want to have the command available somehow without selecting it with my mouse.

I've been bashing my head against the wall here trying to make it work and then found this thread which seems to indicate it simply won't until v6. Is that correct?

For reference I'm currently running Linux Mint 18.3 Sylvia with KDE and using a Dvorak layout but I tested with QWERTY too.

[Mike Reed (dunaden)]

Also of note: tested with "Modern Toolset (Accelerated)" and "Modern Toolset (fallback)" both with no effect on using any of the accelerator keys (but hotkeys operate as expected in all permutations).

[Maciej Suminski (orsonmmz)]

KiCad has migrated to Gitlab, this issue is available here: https://gitlab.com/kicad/code/kicad/-/issues/2918