kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

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
> wxWarpPointer.
>
> 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.
>
> Wayne

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