Delay between keyboard shortcut and mouse location capture

[Drew Van Zandt]

Put mouse above component.
Press M to Move component, immediately move mouse above a different component. Incorrect component (or wire, or....) is moved.

Application: kicad
Version: (5.0.2)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.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_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Seth Hillbrand (sethh)]

5.0.2 is no longer supported. Please test with the current 5.1.4 release and let us know if you still experience the issue.

[Drew Van Zandt (drew-vanzandt)]

Still exists.

Application: KiCad
Version: (5.1.4)-1, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.61.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=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Nick Østergaard (nickoe)]

I have seen similar things, I have not yet had time to attempt to bisect this issue. I think it could be related to some double click detection stuff.

[Ian McInerney (imcinerney)]

I was thinking about this some more, and I think it is related to delays in the processing of events that we do. Currently, the selection actions for move-like commands do not use the position where the key was pressed but instead the position of the mouse when the actual selection functions are called. Unfortuantely, there are quite a few functions between the user pressing a key and these selection functions, and also there may be other events being processed that delay the key press event as well.

The best fix for this will be to modify the way we handle position information in these functions and use the position where the user pressed the key. This might be a fairly invasive change, so it might not make it back into 5.1. If it isn't as invasive as I think, then it could be backported after some testing in master (anything dealing with the tool framework seems to have some risk of introducing new problems).

[Drew Van Zandt (drew-vanzandt)]

That makes sense. This is much more noticeable in the newer version than
in the one I initially reported it on.

*Drew Van Zandt*

On Thu, Oct 10, 2019 at 5:31 AM Ian McInerney <email address hidden>
wrote:

> I was thinking about this some more, and I think it is related to delays
> in the processing of events that we do. Currently, the selection actions
> for move-like commands do not use the position where the key was pressed
> but instead the position of the mouse when the actual selection
> functions are called. Unfortuantely, there are quite a few functions
> between the user pressing a key and these selection functions, and also
> there may be other events being processed that delay the key press event
> as well.
>
> The best fix for this will be to modify the way we handle position
> information in these functions and use the position where the user
> pressed the key. This might be a fairly invasive change, so it might not
> make it back into 5.1. If it isn't as invasive as I think, then it could
> be backported after some testing in master (anything dealing with the
> tool framework seems to have some risk of introducing new problems).
>
> ** Changed in: kicad
> Assignee: (unassigned) => Ian McInerney (imcinerney)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1847318
>
> Title:
> Delay between keyboard shortcut and mouse location capture
>
> Status in KiCad:
> Confirmed
>
> Bug description:
> Put mouse above component.
> Press M to Move component, immediately move mouse above a different
> component. Incorrect component (or wire, or....) is moved.
>
> Application: kicad
> Version: (5.0.2)-1, release build
> Libraries:
> wxWidgets 3.0.4
> libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6
> libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
> Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
> wxMSW
> Build Info:
> wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
> Boost: 1.68.0
> OpenCASCADE Community Edition: 6.9.1
> Curl: 7.61.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_WXPYTHON=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_USE_OCC=OFF
> KICAD_SPICE=ON
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1847318/+subscriptions
>

[Ian McInerney (imcinerney)]

I'm pulling this from 5.1.5 to 6.0 since the backend for Eeschema has already been switched in 6.0, and trying to do this surgery in 5.1.5 would be too likely to introduce more problems.

[KiCad Janitor (kicad-janitor)]

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