← Back to team overview

kicad-developers team mailing list archive

Re: Cursor position improvements.


Le 01/02/2011 22:40, Wayne Stambaugh a écrit :
While trekking though the Kicad source to removed the old zooming code, I
discovered another issue that is going to drive me insane (it's a short drive)
until it gets fixed.  Currently, there are two cursor positions stored in
Kicad.  One is the operating system cursor position and the other is the drawn
cursor position on grid (sometimes).  Both positions are in drawing units.  I
believe this causes some of the bipolar cursor behavior that you occasionally
see in Kicad.  The reason these positions are stored is because the cursor
position is not passed to any of the drawing code.  I did a little testing and
I think both of these positions can be removed.  Here is what I am proposing:

1) Modify all code paths (captured mouse callbacks, mouse clicks, etc.) that
use the current cursor (not the Kicad drawn cursor) to accept this position in
drawing units.

2) Allow the drawing code determine when to snap to grid based on the
application grid snap setting.

3) Use wxWarpPointer to provide snapping to grid on Linux and Windows.  It
turns out that calling wxWarpPointer immediately posts a wxMouseMouse event to
the new position which should allow you to use the normal refreshing code when
zooming in and out.

4) Use the stock cross hair cursor instead of drawing a separate cursor giving
you more consistent behavior between OSX and the platforms that support

Does anyone know of any reason this can't be done.  If it works properly, it
should greatly simplify the drawing code.  If no one objects, I would like to
tackle this before resuming my EESchema refactoring work.


Cleaning code is always good.

I am not sure current mouse position can be always used.
I am thinking to locate functions when called from a popup menu event.
If you want to edit/select... an item, usually you move the mouse cursor on it and right click the mouse.
This is this last mouse position that must be used, and not the current mouse position,
because select a menu option need to move the mouse.
There are some similar cases when using some dialogs.
Of course this is easy to solve, but must be taken in account.

About find menu and cursor move, an option in find dialog seems good,
because sometimes you want to locate and edit a given item (warp mouse is the best)
and sometimes look for all occurrences of a text (warp mouse is not good)

By the way, I will be away next days.
Jean-Pierre CHARRAS

Follow ups