kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 2/2/2011 1:50 AM, jean-pierre charras wrote:
> 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.

Thanks for the input.  I will make sure that the current cursor position is
correct before making any changes.  I plan on implementing this incrementally
to minimize the potential for issues.

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

Hopefully it's to do something fun.  Enjoy.

Wayne