Hotkey list sections should be refined

[Ian McInerney]

Currently the hotkey lists just show hotkeys as being for the main programs Eeschema, Common, Kicad Manager, Pcbnew, etc rather than having other sections for editors such as the symbol editor and footprint editor. This can be somewhat confusing, since that means actions that have no meaning in eeschema are in that heading (such as "Duplicate Symbol", which is only active in the symbol editor, but sounds like it could be used in Eeschema).

The hotkeys list should probably be sorted/organized better to avoid confusion. At a minimum, the headings should only contain the tools that are active in that program's editor (e.g. eeschema only shows the ones active in the schematic editor and another for libedit shows the one active in the symbol editor).

Application: Eeschema
Version: (5.1.0-1195-g1548dcfe8-dirty), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.64.0 OpenSSL/1.1.1c zlib/1.2.11 brotli/1.0.7 libidn2/2.1.1 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.8.7/openssl/zlib nghttp2/1.37.0
Platform: Linux 5.1.15-300.fc30.x86_64 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.69.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.64.0
    Compiler: Clang 8.0.0 with C++ ABI 1002

Build settings:
    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=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

I agree with this assessment that hotkeys shouldn't be mixed under headings where they aren't applicable. Maybe Jeff can expand on the reasons for merging them?

[Jeff Young (jeyjey)]

Many of the hotkeys are shared (particularly between Pcbnew and ModEdit).

If we wanted to go this route then we'd need:

Common
Pcbnew & ModEdit
Pcbnew
ModEdit
Eeschema & LibEdit
Eeschema
LibEdit

or we'd need to allow duplicates in the list and keep them in sync (which might also result in unexpected behaviour).

[Ian McInerney (imcinerney)]

I would actually go a step farther and say that the hotkeys displayed in the preferences window should be for that window only. This would essentially be the way they are handled in the 5.1 branch. As it stands, the contents of the pane changes depending on whether you have pcbnew, eeschema, etc. open (since each will add in its own section).

I believe that much of this display unit is based around the old hotkey architecture, where we had those defined sections in a hotkey store. Is this architecture going to be modified for the new hotkey system where the files have the action names? Perhaps what could be done then is to make it so the tool manager for the frame is queried to find which tools are currently registered, and then that listing is used to generate the displayed hotkey list.

[Jeff Young (jeyjey)]

The old hotkey architecture (with its sections) is gone. The new one is based on the action names (ie: "common.control.zoomIn"), and is generated exactly as Ian suggests (the tool manager is queried for the registered actions).

If we wanted to move things around by changing the action names we'd want to do it soon. Those names are also used to index user-hotkey-definitions, so changing them will lose user-defined hotkeys.

[Ian McInerney (imcinerney)]

@Jeff, is there a way to query if an action in a tool manager has a tool that will handle it associated to that manager? That would make sorting the list in this way far easier, since that information could be used to display only those that would be usable in the frame.

[Jeff Young (jeyjey)]

@Ian, no, not at present.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2455