eeschema jump when block-moving object

[Chris Pavlina]

A user on IRC reports that eeschema pans and places in the wrong spot when block-moving an object. Here's a video he took:

http://misc.c4757p.com/eeschema_prob.ogv

I cannot reproduce this. Can anyone else?

Application: kicad
Version: (2015-07-31 BZR 6030)-product release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.8.3,wx containers,compatible with 2.8)
Platform: Linux 3.16.0-rc5+ x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.54.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[Maciej Suminski (orsonmmz)]

I experience the problem under Linux with awesome window manager. Apparently every left click button event triggers also EDA_DRAW_PANEL::OnMouseLeaving(), but I have no idea why - it might be a WM bug. There is a workaround though: disable "Pan while moving object" in Preferences->Schematic Editor Options.

[Chris Pavlina (pavlina-chris)]

Interesting. I am definitely familiar with WM bugs of a similar nature. Tiling window managers in particular seem to be terribly buggy.

[Maciej Suminski (orsonmmz)]

Here is a patch that resolves the issue by checking if the cursor has really left the window area (I am not brave enough to apply it to the master branch, as I am not sure if there are other consequences).

[Wayne Stambaugh (stambaughw)]

This is definitely something that should be thoroughly tested on as many
window managers as possible before committing. Wouldn't it be better to
just use wxWindow::HitTest() to check if the mouse cursor has left the
drawing area? It seems like a lot code to just to test for something
that wxWidgets already appears to provide. I'm not sure converting the
position to logical units is necessary?

On 8/10/2015 12:13 PM, Maciej Sumiński wrote:
> Here is a patch that resolves the issue by checking if the cursor has
> really left the window area (I am not brave enough to apply it to the
> master branch, as I am not sure if there are other consequences).
>
> ** Patch added: "eeschema_warping_cursor.patch"
> https://bugs.launchpad.net/kicad/+bug/1480584/+attachment/4442306/+files/eeschema_warping_cursor.patch
>

[Felix Esch (esch)]

I have encountered this issue here with awesome wm (v3.5.6) and kicad product build (2015-08-24 BZR 6119).
The patch posted by #3 is working for me.

[Felix Esch (esch)]

Additional information: Kicad works normally when using i3 or kde5 as the window manager. This may be a bug specific to awesome wm.

Platform: Arch Linux

[Wayne Stambaugh (stambaughw)]

OK, so now what? I'm not very thrilled about the prospect of adding code to KiCad to fix a Linux window manager bug. It's bad enough that we have to provide library patches to get things to work. I can see this type of situation spiraling out of control as we add patches for each new WM bug. Has anyone submitted a bug report to the awesome wm project or checked if they are even aware of the problem? As I've stated before, this patch seems like overkill. Does it really need to convert the cursor position to drawing (logical) coordinates to verify if the mouse is within the boundary of the canvas (wxPanel)? I would think you should be able to use the device coordinates to determine if the mouse is within the canvas.

[Nick Østergaard (nickoe)]

I think the best action is to let awesome wm enthusiasts work with awesome wm developers to debug this issue further. It looks to me like this issue is easy to reproduce for those using awesome.

[Felix Esch (esch)]

Well I understand the reluctance to respond to bugs in another project, but the patch for this issue does not add much.
To be specific it remembers the cross-hair position, does the calculation as happened without the patch before and then checks if an update is really necessary by using one if-conditional.
I am not a developer of kicad, but is 1 variable and 1 conditional (a sanity check) and two lines of commentary too much?

[Nick Østergaard (nickoe)]

On the other hand, it is one issue of awesome and one commit to fix it, hopefully. Please report the issue to
https://github.com/awesomeWM/awesome/issues

Weather or not we do a workaround in KiCad is not my decision.

[Felix Esch (esch)]

The issue for awesome can be found on github: https://github.com/awesomeWM/awesome/issues/427

[Wayne Stambaugh (stambaughw)]

@Orson, go ahead and commit this patch. I'm going against my better judgement since @Felix was motivated enough to file an issue against the AwesomeWM. Thank you @Felix, most users wont go to this much trouble so this is why I'm giving you a free pass. Please note that if it causes *any* issues with any other windows managers, it will pulled from the source code immediately. We are trying to get a stable release out the door so you can understand my concerns.