Cross probing highlight in eeschema is missing

[Nick Østergaard]

After the new GAL canvas in eeschema the crosshair that appeared on top of a part when cross-probing from pcbnew to eeschema is gone. eeschema do center properly over the part, so this but is not about the same as described in https://bugs.launchpad.net/kicad/+bug/1766950

How to:
1. open a project which has a matching schematic and board file (you may like to zoom far in in eeschema)
2. click a footprint in pcbnew
3. observe that you no form of marking is used in pcbnew to highlight a selected footprint

Expected:
With the legacy canvas a small crosshair would appear on the center of the symbol in eeschema. I would like to see this feature or a similar implementation back in eeschema gal.

As we got the gal canvas, maybe it is better draw an opaque box around the symbol, sort of similar to what is done with InteractiveHtmlBom, see https://openscopeproject.org/InteractiveHtmlBomDemo/ . Don't be confused with me thinking this is how it should look in pcbnew. All I am trying to say with this is that a possible implementation is to have a red box with a faint red background fill to highlight a symbol.

Application: kicad
Version: (6.0.0-rc1-dev-1119-gd465af65a), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.34.0
Platform: Linux 4.18.16-arch1-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.1
    Compiler: GCC 8.2.1 with C++ ABI 1013

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

[Seth Hillbrand (sethh)]

Nick, is this the same as lp:1796990 ?

[Nick Østergaard (nickoe)]

@Seth, yes it definitely is. Sorry for the duplicate bug report. I did try to see if I could find the bug reported already, but apprently didn't stumble upon that exact one.