Bad move / grid interaction

[Ron Burkey]

In the schematic editor, if you are moving something (say, with 'M', or 'G', or by duplicating a block, etc.) by a small amount, it used to be very convenient to do so with the arrow keys. It used to be that each press of an arrow key would move the item by exactly one grid position.

That is no longer the case, and hasn't been so for perhaps 6-8 months. What happens now is that pressing an arrow key makes the item jump by a very large amount. (I can't quite characterize how much it jumps, since it's not always the same, and seems to depend on the zoom level. But it may be about 10% of the viewport size.)

Now, unfortunately, if you want to move an item by a small amount, you have to try and judge it precisely with the mouse, which is very tricky.

Version info:

Application: kicad
Version: 5.1.0-rc1-unknown-235f2c7~76~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.11 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-53-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

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

[Hildo Guillardi Júnior (hildogjr)]

This is related with the fix https://bugs.launchpad.net/kicad/+bug/1810684
Before, using arrow was causing canvas unsync. But now, the step is zoom dependent: high zooms (in...) move as expected, 1 grid step; but low zooms (out...) move more than 1 grid step.

Propose to fix:
Always move as one-grid-step, independent of the zoom. But, use some exponential acceleration to the move velocity. So, if the user keep the <arrows> presses some millisecond the movement between grid steps will be quicker than just one press.

[Hildo Guillardi Júnior (hildogjr)]

This appear to be solve at 6.0.0-unknown-2e8d930~86~ubuntu16.04.1 release. Could you confirm, @Wayne?

[Ron Burkey (rburkey)]

Sweet! It looks like it works for me too with 2e8d930.

[Nick Østergaard (nickoe)]

Does it make sense to cherry pick the fix in
https://bugs.launchpad.net/kicad/+bug/1810684
to the 5.1 branch?

[Wayne Stambaugh (stambaughw)]

@Nick, I don't think so. I think this fix was part of Jeff's new tool framework changes so it was only broken in the master branch which would only affect nightly builds. @Jeff, am I correct this correct?

[Seth Hillbrand (sethh)]

@Ron- I believe that this is resolved in the current 5.1 branch. Could you test with the 5.1 nightly builds from

https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5-nightly

[Ron Burkey (rburkey)]

@Seth, I'm afraid there will have to be a delay, because I'm obliged at the moment not to ugrade my 5.1 nightly build. (The 5.1 nightly version I'm keeping has stuff in it that no longer works with recent builds and that I can't afford to lose.)

The fix works great in the 6.0 nightly build, but I guess that doesn't help you? It'll probably be a couple of days before I can try out a new 5.1 nightly on a computer I can risk upgrading.

[Ron Burkey (rburkey)]

Yes and no. In the few minutes I've been able to squeeze in to play with it, the problem as I originally described it seems to have been fixed.

But there's a weird effect that undoes some of the goodness and may or may not be related: Suppose I have the grid set to (say) 5 mils. If I'm zoomed in far enough, every time I hit the arrow keys it does move the cursor _and_ whatever I'm trying to 'M' or 'G' by 5 mils in the appropriate direction, just as it ought to.

However, if I'm zoomed out somewhat, it seems as though the cursor doesn't want to move by something as small as 5 mils. So whatever I'm trying to 'M' or 'G' probably won't even move at all when I click the arrow keys. (Or you will see it move a little bit and then snap right back to where it started.) And you can tell for sure it's not moving, because coordinates don't change.

So now it's better than it was, but it's still inconvenient because it still depends on having zoomed in just the right amount to make it work. Before you had to zoom out far enough for it to work properly; now, instead, you have to zoom in far enough to make it work properly.

[Jeff Young (jeyjey)]

While this is really a different bug, I can confirm that it's an issue and one that is very annoying at times.

[Jeff Young (jeyjey)]

This /might/ be fixed. I found a rather insidious bug that didn't have anything to do with zoom or the grid: the move tool would get the event before the cursor control handler, so it would always be one step behind. This made it look like the first arrow did nothing (and even more strange, after arrowing up a few times the first down arrow would move it up one more).

With the fix, the OSX version works pretty nicely, even at very high or very low zooms. I'm going to close this, but if GTK still has other issues please re-open.

[Ron Burkey (rburkey)]

I thought it had been working already, since I hadn't noticed a problem with the last couple of revisions I've used. I'll exercise it tomorrow and pay better attention.

[Jeff Young (jeyjey)]

The 5.1 code is quite a bit different, and quite a bit buggier. I made several changes there (including fixing the most annoying one that it would snap to grid on the axis that /wasn't/ moving as well).

[Ron Burkey (rburkey)]

Unfortunately, I cannot readily test 5.1. Until the regression in bug #1827124 is fixed, I'm stuck on an older rev of 5.1.

[Ron Burkey (rburkey)]

A possibly-related issue I've seen several times this morning in both eeschema and pleditor is that if you're doing a Move and you try to finish it up by hitting the <Enter> key, then it may ignore the first <Enter>. In other words, sometimes you have to hit <Enter> twice to end the Move. However, I've not been able to figure out any way to replicate.

Application: Eeschema
Version: 6.0.0-unknown-becd6a6~86~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.11 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-53-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

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