On Sat, 2008-05-24 at 09:18 +0200, Werner Hoch wrote: > Hi Peter and all, > > I've fixed the mouse_wx/y issue with the last 3 commits of > http://repo.or.cz/w/geda-gaf/werner.git?a=shortlog;h=refs/heads/w_coords2 > > I've removed the global mouse_wx/y variables. I'm now using the > gtk_widget_get_pointer() function to get the position of the pointer > whenever a hotkey action is triggered.
I like the cleanup and avoidance of global state variables. This probably causes an extra server round-trip. I guess if its only hotkey events, so its not burdensome, but in theory we should get mouse coordinate data when we receive the keypress event in x_event_key_press - we just don't pass it on. If we passed on that data, would we still need the API? I'm wondering whether using gEDA over a remote X11 connection could lead to the mouse having moved between the keypress event and when the gtk_widget_get_pointer() call is made. > The gtk function is encapsulated in the function > x_event_get_pointer_position(). Thus I can get the pointer position in > world coords, snapped or unsnapped and with a boolean result, whether > the pointer is inside the drawing area. > > The boolean result is used in the callbacks to ignore all hotkey action > if the pointer is outside the drawing area. > > This function is used now in all places where the pointer position is > required. > * gschem callbacks > * preview widget > * attribedit dialog Don't use: gtk_object_set_data() and gtk_object_get_data() for new code, use: g_object_set_data() and g_object_get_data() (Only use the deprecated gtk_... API if interacting with old code which uses it. Even then, fixing up the old code would be better) I'm not generally a fan of using the data-stashing APIs, in the future it might be nice to make the attrib dialog a subclass of gschem_dialog, and add these data-fields as properties. > This commits should fix several issues with the current code. > > The global mouse_wx/y variable was used in the preview widgets and the > drawing area. The variables got updated whenever a motion event was > triggered. > > There have been several actions, where no motion is done and the > following actions have been using the wrong values of the mouse > position. > > * The motion was done in a preview, then the focus changed to the main > window (without motion using ALT-tab) followed by an hotkey action like > draw line --> wrong start coords. Ahah.. I wondered what caused that! [snip] > Any comments? > > I will use the code a few days and push it to the git repo if there are > no further issues with it. Looks good to me. I'd not bother with sub-classing the attribute editor, just change to using the g_... API rather than the gtk_... for data stashing, and it looks pretty good. Is there any way we can pass on the original x/y data from the keypress events though? Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
