The "target" was seen moving from 0,0 to the first calibration
point, so 1) avoid target relayouts when the window is still
being positioned and 2) start the "target" actor as hidden so
it isn't seen moving from anywhere when first shown.
https://bugzilla.gnome.org/show_bug.cgi?id=719698
Keep the reference for the error/helper messages animations in
the CalibArea struct, so those are destroyed and not leaked, or
possibly crashing when running on already destroyed actors if
the dialog gets cancelled at the right time.
https://bugzilla.gnome.org/show_bug.cgi?id=719698
The calibration gui code moved the targets to x,y, instead of
placing the centre of the target at x,y, leading to a 47 pixel
(half the target's size) offset in both directions (thus 67 pixels
deviation as Pythagorus would tell us).
We were always getting the events from the core pointer instead
of the device itself, so threw all of them away.
We need to get the real source device from the event.
https://bugzilla.gnome.org/show_bug.cgi?id=707784
We receive ClutterEvents, not GdkEvents for button presses on
ClutterActors, so use the correct functions to filter devices.
This also fixes the offset used to access the coordinates of the
events. We were actually using the pointer to the source and x
struct members instead of x and y.
https://bugzilla.gnome.org/show_bug.cgi?id=707784
The name of the file was also changed to calibratorgui.c/h to avoid
it being inconsistent, this way it is no longer dependent on the
the technology.
https://bugzilla.gnome.org/show_bug.cgi?id=667797
