Go forward in time to March 2009.
I have started a tracker bug for RANDR-related problems in all of GNOME (you can use the bug alias randr-tracker). If you know of bugs in the GNOME Bugzilla that have to do with multiple monitors, projectors, or generally anything RANDR-related, please mark them as blocking that bug. Thanks!
Stanislav Brabec just found an interesting class of bugs when GTK+ apps run on slow or loaded machines. One example is that you click on a notebook's tab and move the mouse away, and the tab "accidentally" gets detached. Another example is that you click-drag-release to select text on a GtkTextView, and the selection doesn't end where you think you released the mouse.
Both bugs have the same root cause. Basically, the event handlers get a mouse event but they don't really use the event's coordinates. Instead, they use gdk_window_get_pointer().
The problem is that by the time gdk_window_get_pointer() is called, the mouse may already have moved with respect to the time when the original event was generated. The effect of this is that you release the mouse, and "things happen" not where you released it, but where you moved it afterwards.
Remember that X is an asynchronous windowing system. "Where is the mouse right now?" is a question that does not make sense in X. You need to use the coordinates that you got from an event, or you risk having bugs like those mentioned above.
Update: we now have a tracker bug for this: tracker bug to sanitize motion event handling.
Go backward in time to January 2009.Federico Mena-Quintero <email@example.com> Thu 2009/Feb/12 22:39:46 CST