kicad warps mouse

[David Lamparter]

kicad warps the mouse (i.e. changes the mouse pointer location).

This indiscutably violates most basic rules of user interface design and breaks for example working with a graphics tablet.

Refer to e.g. http://developer.gnome.org/accessibility-devel-guide/3.0/gad-checklist.html.en
"MI.4 The mouse pointer is never warped under application control, or its movement restricted to part of the screen by the application. "

(not that this is NOT specific to Gnome. Any application, whatever and whereever, MUST NEVER WARP THE MOUSE POINTER, unless this behaviour is explicitly requested by the user.)

[Dick Hollenbeck (dickelbeck)]

On 07/26/2011 07:08 PM, David Lamparter wrote:
> Public bug reported:
>
> kicad warps the mouse (i.e. changes the mouse pointer location).
>
> This indiscutably violates most basic rules of user interface design and
> breaks for example working with a graphics tablet.
>
> Refer to e.g. http://developer.gnome.org/accessibility-devel-guide/3.0/gad-checklist.html.en
> "MI.4 The mouse pointer is never warped under application control, or its movement restricted to part of the screen by the application. "
>
> (not that this is NOT specific to Gnome. Any application, whatever and
> whereever, MUST NEVER WARP THE MOUSE POINTER, unless this behaviour is
> explicitly requested by the user.)

Or else what? We don't get paid?

:)

Perhaps you might get more mileage by asking

1) why we are warping the pointer,
2) who currently thinks it is a good idea,
3) and would anyone be willing to reconsider.

But coming in acting like we don't know the GNOME guidelines is presumptuous and
non-motivational.

Moreover, you did not say under what circumstance the pointer is warped, nor in
which specific program, for the guy who wrote the code 50,000 lines ago.

One of the poorer bug reports that I have seen.

[Lorenzo Marcantonio (l-marcantonio)]

On Wed, 27 Jul 2011, Dick Hollenbeck wrote:

> Perhaps you might get more mileage by asking
>
> 1) why we are warping the pointer,
> 2) who currently thinks it is a good idea,
> 3) and would anyone be willing to reconsider.
>
> But coming in acting like we don't know the GNOME guidelines is presumptuous and
> non-motivational.
>
> Moreover, you did not say under what circumstance the pointer is warped, nor in
> which specific program, for the guy who wrote the code 50,000 lines ago.
>
> One of the poorer bug reports that I have seen.

Well, style apart, he *does* have a good point... I tought to report the same
thing at one time but then the solution would be a bad hit for usability
instead...

The disapproval for warping goes back to Xlib! it says, from
XWarpPointer(3):

     There is seldom any reason for calling this function. The pointer
     should normally be left to the user. If you do use this function,
     however, it generates events just as if the user had instantaneously
     moved the pointer from one position to another.

There are IIRC two instances of pointer warping:
1) Searching (can be disabled)
2) Scrolling/recentering

Obviously removing warping from 2) detracts from usability since it gets
the wire/track out of control (wherever the pointer lands in the new
coordinate space), for example: I'm pulling a track right, the cursor
hits the border, automatic scroll kicks in and a recenter occurs; now
the cursor is *a lot* to the right and I have to move left to recover
from the jump.

Another thing which is useful for (it is in fact the same recentering
behaviour applied to a common gesture) is quickly panning with the mouse
wheel: zoom out, move a little, zoom in is a really quick and precise
way to reposition the view (especially in pcbnew when you are trying to
follow a track, otherwise you lose your way in the copper river :D).

Anyway, I don't care for whatever style guidelines they want us to
adhere to. Also if he has trouble with a tablet he obviously have it in
'relative mode' (which is a bad idea anyway).

I would suggest to put an option for disabling it near the 'automatic
scroll' one, so the user has a choice if s/he wants.

--
Lorenzo Marcantonio
Logos Srl

[David Lamparter (equinox-launchpad)]

On Wed, Jul 27, 2011 at 02:17:57AM -0000, Dick Hollenbeck wrote:
> On 07/26/2011 07:08 PM, David Lamparter wrote:
> > Public bug reported:
> >
> > kicad warps the mouse (i.e. changes the mouse pointer location).
> >
> > This indiscutably violates most basic rules of user interface design and
> > breaks for example working with a graphics tablet.
> >
> > Refer to e.g. http://developer.gnome.org/accessibility-devel-guide/3.0/gad-checklist.html.en
> > "MI.4 The mouse pointer is never warped under application control, or its movement restricted to part of the screen by the application. "
> >
> > (not that this is NOT specific to Gnome. Any application, whatever and
> > whereever, MUST NEVER WARP THE MOUSE POINTER, unless this behaviour is
> > explicitly requested by the user.)
>
> Or else what? We don't get paid?

Or else your software has a bug. Honestly, I've started pretty low, so
your response is to drag it down further?

> Perhaps you might get more mileage by asking
>
> 1) why we are warping the pointer,
> 2) who currently thinks it is a good idea,
> 3) and would anyone be willing to reconsider.

No. This is as elementary as a calculator showing 1 + 1 = 3.

> But coming in acting like we don't know the GNOME guidelines is presumptuous and
> non-motivational.
>
> Moreover, you did not say under what circumstance the pointer is warped, nor in
> which specific program, for the guy who wrote the code 50,000 lines ago.

I'm sorry for expecting that you use the software you're maintaining. As
Lorenzo posted, it happens when you open any of the CAD editing windows,
and also at using the mouse wheel to zoom in/out.

I did not experience the problem on searching, probably since I ticked
off the appropriate box in my search for a way around the bug.

For your reference, the following workaround fixes the issue and has
allowed me to stop my desires to punch someone in the face:

--- a/common/drawpanel.cpp 2011-05-25 12:44:32.000000000 +0200
+++ b/common/drawpanel.cpp 2011-07-27 11:27:19.028600159 +0200
@@ -275,7 +275,6 @@
                     screenPos.x, screenPos.y, x, y );
     }

- WarpPointer( screenPos.x, screenPos.y );
 }

The scrolling behaviour is obviously erratic after this, but compared to
the original issue that's almost nothing.

> One of the poorer bug reports that I have seen.

Consider that an indication of the rage your bug causes. I have never
even been this enraged by any application crash, kernel panic or even
data loss -- probably because I know that someone, somewhere, in pure
disregard of everything that user interface researchers have come up
with, decided that it's a funny idea to jump the mouse around.

-David

[Jerry Jacobs (jerkejacobs-deactivatedaccount)]

Warping possibly introduces also some bad behaviour on OS X, when the scroll action is performed many times after each other the viewport zooms and scrolls up at the same time.

[Dick Hollenbeck (dickelbeck)]

> For your reference, the following workaround fixes the issue and has
> allowed me to stop my desires to punch someone in the face:
>
> --- a/common/drawpanel.cpp 2011-05-25 12:44:32.000000000 +0200
> +++ b/common/drawpanel.cpp 2011-07-27 11:27:19.028600159 +0200
> @@ -275,7 +275,6 @@
> screenPos.x, screenPos.y, x, y );
> }
>
> - WarpPointer( screenPos.x, screenPos.y );
> }
>

I remain unmotivated, even though I myself have previously raised the issue of
warping, and don't particularly care for it.

A little less coffee, a little more diplomacy might push this bug report further
along, but maybe not.

[David Lamparter (equinox-launchpad)]

On Wed, Jul 27, 2011 at 02:13:12PM -0000, Dick Hollenbeck wrote:
> > For your reference, the following workaround fixes the issue and has
> > allowed me to stop my desires to punch someone in the face:
> >
> > --- a/common/drawpanel.cpp 2011-05-25 12:44:32.000000000 +0200
> > +++ b/common/drawpanel.cpp 2011-07-27 11:27:19.028600159 +0200
> > @@ -275,7 +275,6 @@
> > - WarpPointer( screenPos.x, screenPos.y );
>
> I remain unmotivated, even though I myself have previously raised the issue of
> warping, and don't particularly care for it.
>
> A little less coffee, a little more diplomacy might push this bug report further
> along, but maybe not.

I remain pissed enough to maybe even sit down and make a proper patch
(i.e. actually fixing zoom to do something sensible) for this atrocity,
but on the other hand my coffee supply isn't infinite and I have an
EAGLE license. Oh noes.

FWIW, I have no clue why nobody else reported this. I would recommend
you to regard this issue independent of its flaming reporter; since you
say you were already aware of it I guess you might interpret my rage as
indication of its severity.

[Lorenzo Marcantonio (l-marcantonio)]

On Wed, 27 Jul 2011, David Lamparter wrote:

> I remain pissed enough to maybe even sit down and make a proper patch
> (i.e. actually fixing zoom to do something sensible) for this atrocity,
> but on the other hand my coffee supply isn't infinite and I have an
> EAGLE license. Oh noes.

A colleague of mine has a full Altium license package. 15000EUR of stuff. But for non-highspeed circuits find kicad more efficient. Even if it has a warping mouse:D (OTOH it seems that to fully use Altium you need 3 monitors, reading their brochures XD)

> FWIW, I have no clue why nobody else reported this. I would recommend
> you to regard this issue independent of its flaming reporter; since you
> say you were already aware of it I guess you might interpret my rage as
> indication of its severity.

You could propose the sensible thing to do, maybe someone will implement that. The 'obvious' alternative (simply disabling warping) greatly detract from usability, but can be put in the wishlist (heck, it's a checkbox and a configuration parameter, about 30 minutes of work if you're good with the form editor --- which I am not).

Flaming or not I agree that could be a problem for some people, but I simply don't have a better solution for now.

And, personally, I'd prefer work on some more useful features (i.e. pad and via handling and the new format)

--
Lorenzo Marcantonio
Logos Srl

[Krzysztof Wesołowski (kwesoly)]

KiCAD GUI has multiple "bugs" which make it not intuitive. But one can get used to them, whiel reporting them and receiving "Triaged" notifications also is demotivational ;)

I find mouse warping extremely irritating when cursor is warped to place where context menu was opened, after i close this menu with Esc key and my pointer is on the way to other function...

[Dick Hollenbeck (dickelbeck)]

This is proof that communism can never work.

The recipient of the free stuff is de-motivated.

[Timmmm (tdhutt)]

Yeah, I just started doing electronics and am pretty disappointed with the OSS offerings, given that is isn't exactly a terribly complicated problem, like CAD or video editing... Five minutes of using kicad tells me that either the authors never used the software, or are crazy masochists!

Mouse warping was the first craziness, but let's look at some other bugs that I found. Note that this was literally within 5 minutes of using the program. How these haven't been noticed and fixed is beyond me:

1. Mouse warping in many places.
2. There are two mouse cursors - cross and pencil. Just seems weird; hide the pencil.
3. I got to "Insert Component" fine, but then what do you do? Seems not very discoverable, I guess I'll click "Search by keyword." Needless to say this did not do what I expect. Why don't you should the component library when you click "Insert component"?
4. Ok, so I found the Library Browser, but once you've found part what do you do? There's no ok button. Double clicking does nothing. In the end I have to hover all the toolbar buttons. Not exactly friendly.
5. Moving the splitters breaks the UI!
6. Ok now I want to move a component. I click and drag it, but that creates a rubber band... and moves is... and the rubber band? Wtf is going on?
7. Ok so now I want to delete the component. I try to select it by dragging a box around it, or clicking it. Neither seems to work. I right click it, and it says the delete shortcut is DEL, but how the hell do I select it so I can press that?! Eventually I found out you hover over it and then press del.

And so on. I still haven't found out how to export a netlist (or whatever it is I need to do to get to the PCB stage).

Stop messing with the standard UI conventions that work very well and have been around for decades! For an example of how it *should* be done, see Dia, or better, IPE. In fact I think IPE could be turned into a good schematic/PCB editor without too much effort. Perhaps less effort than would be needed to make kicad sane.

For what it's worth, Eagle also has a retarded UI. I haven't tried geda yet but I have low hopes.

/rant.

PS: I hope this is more motivational than demoralising; prove me wrong (by fixing stuff)!

[Lorenzo Marcantonio (l-marcantonio)]

On Thu, 15 Sep 2011, Timmmm wrote:

> For what it's worth, Eagle also has a retarded UI. I haven't tried geda
> yet but I have low hopes.

No EDA has a standard UI because standard UI is *not* useful for the
kind of work it needs to be done... for example warping *is* very
useful, actually (use LTSpice if you want to suffer because there is no
warping), especially when routing traces. I agree that there should be
an option to disable it, tough.

As for other issues there are some nice ideas in there... for example
I somehow like the ISIS component bar (a *big* listbox containing the
available parts, more or less the component browser in permanent form
near the toolbar). OTOH I'd like some kind of 2 keys macro for adding
single characters component (like A,R for resistors and A,C for
capacitors) to work faster (heck, we're paid by the hour but we have
deadlines :P)

Also (in ISIS) there is a component option of where to connect
the 'hidden' power pins... without it the hidden pin feature is
absolutely worthless for pro use (since we have tons of power rails
around). As a related notes hidden pins are not recommended because 1)
it is not evident where the part is powered from 2) you need to notate
somewhere else the bypass capacitors (never leave home without them :D)
and 3) in some kind of design there is a filter cap/ferrite on *each*
power pin so you need to show them anyway!

Also, learn your shortcut keys! The original orcad did *everything* with
single keys (something like vi) and everyone lamented when cadence
windowsized it... (there are *still* around pcb386 user groups, BTW so
it was a successful design!) A while ago someone contested there was
no menu option/toolbar for the relative zero (the space key). Of course
there is not! Since it works for the current position... choosing the
option and then clicking the position would *not* be useful, since it's
mostly used when moving stuff (i.e. doing something else...).
A 'measure' tool would be useful for the obvious function (measuring
distances) but, as a colleague of mine said (after asking for how to
measure stuff) "the space bar is way faster"

For the netlist there is a big nice button in the toolbar :D (in the
devel IIRC there is also in the menu bar, since they reorganized them)

As for the 'delete after selection'... in a text editor do you need to
select the character to delete it with Del or Backspace? of course
not... parts, wires and junctions are the 'characters' for an EDA
program... you rubberband to select if you want to do massive operations
(and you'll quickly learn that is faster to shift-drag or ctrl-drag to
copy or drag, because it's way faster than right select from the
menu...)

BTW you said the 'moving the splitters breaks the UI'... which
splitters??? since when kicad has splitters???

--
Lorenzo Marcantonio
Logos Srl

[iu1j4 (y0g1)]

Hello,
I don't know if it is right place for my comment.
I tested Kicad from bzr (3200) and noticed, than in pcb the cursor changes position
during zoom, unzoom (with mouse wheel).
It is strange, becouse the pointer move outside kicad window area to top left or right bottom corner.
When the pointer moves into top left corner, then kde switchs into windows previews mode.
When the pointer moves into bottom right corner when is my taskbar located, then the mouse weel
changes active window.
It is related to pcb only. In eeschema there is no such behaviour.
Is it e future, or a bug? How to restore working wheel zoom in pcb ?

[iu1j4 (y0g1)]

I have checked the suggestion:
--- a/common/drawpanel.cpp 2011-05-25 12:44:32.000000000 +0200
+++ b/common/drawpanel.cpp 2011-07-27 11:27:19.028600159 +0200
@@ -275,7 +275,6 @@
                     screenPos.x, screenPos.y, x, y );
     }

- WarpPointer( screenPos.x, screenPos.y );
 }

to delete WarpPointer() from drawpanel.cpp and it helped.
Why do You nedd to use WarpPointer() ?

[iu1j4 (y0g1)]

In drawpanel.cpp there is something like this:
286
        if( screenPos.y < clientRect.GetTop() )
287
            y -= m_scrollIncrementY * yPpu;
288
        else if( screenPos.y > clientRect.GetBottom() )
289
            y += m_scrollIncrementY * yPpu;
290
        else if( clientRect.GetRight() < screenPos.x )
291
            x += m_scrollIncrementX * xPpu;
292
        else
293
            x -= m_scrollIncrementX * xPpu;
Why do You mix checking vertical and horizontal ranges together?
It would be more clear to use something like:
if(vertical rule)
else if(another vertical rule)
else

and
if(horizontal rule)
else (another horizontal rule)
else ..

I am not c++ developer, so I may be wrong, but in my opinion it could
be potential place for bug.
Can someone check it ?

[iu1j4 (y0g1)]

One more idea from me.
It would be great if zooming function will not change current pointer position.
For example:
I heve got pointer over R2 elemnt. During zoomin or zoomoout the pointer should
always stay over R2 element (in eeschema and pcb).
Cound You do that?
Correct it please.

[Dick Hollenbeck (dickelbeck)]

On 10/30/2011 03:58 AM, iu1j4 wrote:
> One more idea from me.
> It would be great if zooming function will not change current pointer position.
> For example:
> I heve got pointer over R2 elemnt. During zoomin or zoomoout the pointer should
> always stay over R2 element (in eeschema and pcb).
> Cound You do that?
> Correct it please.
>

This is a matter of personal preference.

I find that having the mouse pointer stay at the same spot on the board is important.
There may be more than one way to do this, but what is currently being done seemingly
accomplishes this.

Dick

[Wayne Stambaugh (stambaughw)]

This sounds like a bug. The cursor should warp to the center of the
window and the drawing position where you first zoomed from should be
scrolled to the center of the screen keeping the mouse pointer directly
over the original zoom position. I just checked KiCad testing branch
r3206 on Debian Testing (wxWidgets 2.8.12) and Windows XP (wxWidets
2.9.2) and it appears to work correctly. The cursor should never warp
out of the drawing window. You didn't include any of the platform or
build information so it will be difficult to resolve this problem. In
the future select "Copy Version Information" from the "Help" menu and
paste the results into your bug report. This will give the developers a
lot of useful information. This probably should be filed as a separate
bug report. This bug report was a wishlist item to eliminate the mouse
warping completely or at least have an option to disable it.

On 10/30/2011 3:55 AM, iu1j4 wrote:
> Hello,
> I don't know if it is right place for my comment.
> I tested Kicad from bzr (3200) and noticed, than in pcb the cursor changes position
> during zoom, unzoom (with mouse wheel).
> It is strange, becouse the pointer move outside kicad window area to top left or right bottom corner.
> When the pointer moves into top left corner, then kde switchs into windows previews mode.
> When the pointer moves into bottom right corner when is my taskbar located, then the mouse weel
> changes active window.
> It is related to pcb only. In eeschema there is no such behaviour.
> Is it e future, or a bug? How to restore working wheel zoom in pcb ?
>

[iu1j4 (y0g1)]

I run kicad bzr version on Slackware64 linux with wxWidgets-2.9.2 and gcc-4.6.2
I did some more tests, and for example zoomin works ok, but after that i roll wheel to
do zoomout (one step) and after that mouse pointer goes to left upper corner of the window.
When I move it again to center of the window, then zomm out works ok.
If I do that holding mouse in my hand and move it a bit then it go out of the window.
Without touching mouse (just zomming out without move).
I would like to fix it, but I don't know kicad code structure.
Why do You mix vertical position with horizontal in one if/else if/else construction?
Are You shure that bellow code in drawpanel.cpp is correct?
286
        if( screenPos.y < clientRect.GetTop() )
287
            y -= m_scrollIncrementY * yPpu;
288
        else if( screenPos.y > clientRect.GetBottom() )
289
            y += m_scrollIncrementY * yPpu;
290
        else if( clientRect.GetRight() < screenPos.x )
291
            x += m_scrollIncrementX * xPpu;
292
        else
293
            x -= m_scrollIncrementX * xPpu;
If it is correct, where should I look to find zomming calculation function?

[Wayne Stambaugh (stambaughw)]

I don't have your problem on 64 bit Debian testing with wxWidgets 2.8.12.
wxWidgets 2.9 is an experimental branch of wxWidgets and may contain bugs that
do not exist in the 2.8 branch. KiCad only uses 2.9 on Windows builds because
it solves some rendering issues when the zoom value is not an integer. The
code you are referring to is not the scrolling code. It is the automatic
panning code that adjusts the scroll bars as you attempt to move an object
outside the drawing area. The code you are looking for is
EDA_DRAW_FRAME::::AdjustScrollBars() in common/drawframe.cpp. However, given
that this code works correctly in Windows with wxWidgets 2.9.2 and on Linux
with wxWidgets 2.8.12, I guessing the problem lies in the scrolling or device
context (use to convert between device and logical units when warping the mouse
pointer) code for the Linux version of wxWidgets 2.9. Your best bet would be
to compile against wxWidgets 2.8.12 and see if the problem still exists. If it
goes away, the problem is in wxWidgets 2.9.2 and then you will be
troubleshooting wxWidgets not KiCad.

On 10/31/2011 1:36 PM, iu1j4 wrote:
> I run kicad bzr version on Slackware64 linux with wxWidgets-2.9.2 and gcc-4.6.2
> I did some more tests, and for example zoomin works ok, but after that i roll wheel to
> do zoomout (one step) and after that mouse pointer goes to left upper corner of the window.
> When I move it again to center of the window, then zomm out works ok.
> If I do that holding mouse in my hand and move it a bit then it go out of the window.
> Without touching mouse (just zomming out without move).
> I would like to fix it, but I don't know kicad code structure.
> Why do You mix vertical position with horizontal in one if/else if/else construction?
> Are You shure that bellow code in drawpanel.cpp is correct?
> 286
> if( screenPos.y < clientRect.GetTop() )
> 287
> y -= m_scrollIncrementY * yPpu;
> 288
> else if( screenPos.y > clientRect.GetBottom() )
> 289
> y += m_scrollIncrementY * yPpu;
> 290
> else if( clientRect.GetRight() < screenPos.x )
> 291
> x += m_scrollIncrementX * xPpu;
> 292
> else
> 293
> x -= m_scrollIncrementX * xPpu;
> If it is correct, where should I look to find zomming calculation function?
>

[iu1j4 (y0g1)]

Thanx for reply Wayne,
I installed wxWidgets 2.8.12 and there is no problems with zommin and zoomout in kicad.
It may be wxWidgets 2.9.2 problem, so I will wait for final stable 2.9 branch of it.

[jean-pierre charras (jp-charras)]

Le 01/11/2011 11:50, iu1j4 a écrit :
> Thanks for reply Wayne,
> I installed wxWidgets 2.8.12 and there is no problems with zommin and zoomout in kicad.
> It may be wxWidgets 2.9.2 problem, so I will wait for final stable 2.9 branch of it.
>

Can you test the 2.9.3 version ?
This is the current svn version and must be downloaded from the wxWidgets SVN server.
I am using it under Windows and Linux to develop and test KiCad, and it works pretty well.
With with version I did not noticed this problem (Ubuntu 10 version), at least when the mouse is inside the page limits.
When the mouse is outside the page limits, this kind of problem exists for some zoom values in all platforms,
but this is currently a (known) KiCad limit.

--
Jean-Pierre CHARRAS

[Wayne Stambaugh (stambaughw)]

On 11/1/2011 7:51 AM, jean-pierre charras wrote:
> Le 01/11/2011 11:50, iu1j4 a écrit :
>> Thanks for reply Wayne,
>> I installed wxWidgets 2.8.12 and there is no problems with zommin and zoomout in kicad.
>> It may be wxWidgets 2.9.2 problem, so I will wait for final stable 2.9 branch of it.
>>
>
> Can you test the 2.9.3 version ?
> This is the current svn version and must be downloaded from the wxWidgets SVN server.
> I am using it under Windows and Linux to develop and test KiCad, and it works pretty well.
> With with version I did not noticed this problem (Ubuntu 10 version), at least when the mouse is inside the page limits.
> When the mouse is outside the page limits, this kind of problem exists for some zoom values in all platforms,
> but this is currently a (known) KiCad limit.
>

I see whats happening now! I can duplicated this on Linux with 2.8.12 and
Windows with 2.9.2 and I'm guessing everywhere else as well. You can easily
duplicate this by zooming all the way out in Eeschema or Pcbnew and moving the
cursor to the upper left portion of the drawing area and begin zooming in. You
will see the cursor warping up and to the left until it eventually warps out of
the drawing panel. I thought I had fixed this a long time ago. The reason I
didn't see it before is that as long as mouse cursor is within the drawing area
when zooming in, this behavior doesn't happen. I think this is due to an
offset error when the drawing is zoomed way out and becomes a fraction of the
drawing window. There is a likely mismatch between the scroll bar offset and
the drawing offset when zoomed way out which causes the problem. I'll take a
look at it and see if I can figure it out.

[Wayne Stambaugh (stambaughw)]

I committed the changes to fix the mouse warping off the drawing area. I think it covers all possible use cases but I would like someone else to test it. If you find that the mouse still warps off the drawing area please let me know how you did it so I can take another look at it.

Wayne

[Lorenzo Marcantonio (l-marcantonio)]

On Sat, Mar 17, 2012 at 11:55:03PM -0000, Stefan D. wrote:
> ** Also affects: kicad (Ubuntu)
> Importance: Undecided
> Status: New

Please please please stop this bug report... it was already discussed a gadzillion of times

--
Lorenzo Marcantonio
Logos Srl

[Stefan D. (stefan-sdroege)]

Hi, here I send you a patch, that performs the zooming in a more natural way.
It is *not* just disabling the mouse warping or only zooming to the screen center. Instead the new zooming enables the possibility to zoom in on a spot, without having to readjust your eyes on a new location of the spot.

Please check it out and tell me what you think.

P.S. Sorry for adding the "Also affects: kicad (Ubuntu)" thing. I'm relativly new at launchpad. This was perhaps a bit to harsh for a non show-stopper bug.

[Dick Hollenbeck (dickelbeck)]

On 03/22/2012 01:03 PM, Stefan D. wrote:
> Hi, here I send you a patch, that performs the zooming in a more natural way.
> It is *not* just disabling the mouse warping or only zooming to the screen center. Instead the new zooming enables the possibility to zoom in on a spot, without having to readjust your eyes on a new location of the spot.
>
> Please check it out and tell me what you think.
>
> P.S. Sorry for adding the "Also affects: kicad (Ubuntu)" thing. I'm
> relativly new at launchpad. This was perhaps a bit to harsh for a non
> show-stopper bug.
>
>
> ** Patch added: "natural_zooming.patch"
> https://bugs.launchpad.net/kicad/+bug/816739/+attachment/2917364/+files/natural_zooming.patch
>

Stefan,

Works really nicely, just tried it.

(However, now I'm finding that I need some streamlined way to pan.
Where did that patch which claimed to support middle mouse button panning go?
Looking for it now.... )

The two patches may complement each other quite well, in concept.

Dick

[Dick Hollenbeck (dickelbeck)]

Stefan,

I would be in favor of committing this one right next to lagos's if we can work out his
end of travel issue.

I think one patch needs the other.

Nice clean work.

Others are welcome to try it.

If nobody screams I will commit it when we can do it with lagos' middle mouse panning patch.

Dick

[Lorenzo Marcantonio (l-marcantonio)]

On Thu, Mar 22, 2012 at 07:26:10PM -0000, Dick Hollenbeck wrote:
> (However, now I'm finding that I need some streamlined way to pan.
> Where did that patch which claimed to support middle mouse button panning go?
> Looking for it now.... )
>
> The two patches may complement each other quite well, in concept.

Anyway try to put an option to retain the old behaviour, I find it more
useful for routing work... I don't care if some UI rules mandate against
it :P

--
Lorenzo Marcantonio
Logos Srl

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "natural_zooming.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Dick Hollenbeck (dickelbeck)]

Honestly, after using the patch for a day, I agree with Lorenzo.

We need a compile time option for this patch.

[Stefan D. (stefan-sdroege)]

I would prefer an option that is adjustable by the user in the preferences (or at least a documented option in a config file), since most users of the kicad suite might not want to recompile kicad just to switch the zooming behavior.

[Dick Hollenbeck (dickelbeck)]

On 03/26/2012 10:54 AM, Stefan D. wrote:
> I would prefer an option that is adjustable by the user in the
> preferences (or at least a documented option in a config file), since
> most users of the kicad suite might not want to recompile kicad just to
> switch the zooming behavior.

No objections to a better patch that would do this, but please wait a couple of days.

BZR is not handling wxformbuilder projects elegantly, is not merging edits, so if you
don't base your patch on a good starting point, it will be potentially omitting stuff
which is in the pipeline before you, such as the panning patch.

I think there are two patches in the queue, not committed yet, at least.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Emmeran (emmeran)]

This bug has been partially resolved with the new off center zooming feature:
https://code.launchpad.net/~emmeran/kicad/kicad/+merge/146282

It can be used by enabling it permanently in the options or just holding down ALT while using the mousewheel.

[Nick Østergaard (nickoe)]

I will add this as incomplete, because the bug is old, partially fixed and the bug description simply does not describe the bug accureately.

[Wayne Stambaugh (stambaughw)]

I think this has been completely fixed. An option was added to disable cursor warping so this can be tagged as fix committed as far as I can tell.

[Nick Østergaard (nickoe)]

Ok, I will mark it is fix comitted then. Anyone who does not think so are free to comment.

[Eldar Khayrullin (eldar)]

Try the Stable Release 4.0.2

[Timothée Manaud (timothee)]

This issue is still present in version: no-vcs-found-bf44d39~61~ubuntu16.04.1
When opening/closing component/module properties.

[Jeff Young (jeyjey)]

Interesting. Warps back when accessed via right-click-context-menu-properties, but not when accessed via hover-hotkey-E. Same for Move Exactly vs. cmd-M, etc.

The warp after a context menu invokes an interactive tool is clearly useful. Probably not after a dialog.

This bug report is too unwieldy to get attention, though, so I'm going to log it as a new issue and close this one again. (New bug: https://bugs.launchpad.net/kicad/+bug/1745731.)