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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
