Hi Peter, On Samstag, 24. Mai 2008, Peter Clifton wrote: > 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_c > >oords2 > > > > 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.
Don't think so. The keypress event (GdkEventKey) does not contain the pointer position. http://library.gnome.org/devel/gdk/stable/gdk-Event-Structures.html > 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. Indeed, if we immediatly get the pointer position, the chance (time) to move the pointer between the key event and the call of the gtk_widget_get_pointer() function would be reduced. But I think we still need the get the position of the pointer from the x server. Second, if we move the function gtk_widget_get_pointer() to x_event_key_press, it would be called for every keypress event, not only for events that require a pointer position. > > * 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) Let's just say it is old code ;-). Let's do the cleanup next time we clean up all dialogs. > 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. Agreed. > > 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? We can pass them adding some variable to GSCHEM_TOPLEVEL. But as the pointer position is not part of the keypress event I don't see much advantage of it. Regards Werner _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
