As x11 considers num lock and scroll lock to be modifiers, code that
checks for an exact modifier combination will fail if naively done when
num lock or scroll lock are turned on. Applications that want to ignore
these modifiers will need to use XKB to manually mask out the modifier
state.
As it is very unlikely that applications will want to care about the
state of num lock or scroll lock for key press/key release events, mask
out the num lock and scroll lock keys automatically.
https://bugzilla.gnome.org/show_bug.cgi?id=690664
This has been disabled since February 2008, on the grounds that XFixes
didn't work reliably for hiding cursors. This has almost certainly been
fixed then and seems to work entirely reliably across a number of X
servers released in the past few years, and is definitely better than a
1x1 black dot for a cursor.
Helpfully though, where the spec states that the cursor will be hidden
when inside the specified window or one of its children, it actually
only uses the window to look up the Screen, and hides the cursor across
the entire Screen. So, when using this, we also need to track crossing
events.
If it's still broken, this needs to be fixed in the X server.
https://bugzilla.gnome.org/show_bug.cgi?id=690497
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Someday, somebody will have to explain to me how not touching
anything for a whole release cycle ends up breaking the build.
Adding the top_srcdir/doc/cookbook path to the includes fixes the
distcheck.
The _clutter_process_event() function may get called while already
servicing a _clutter_process_event() invocation (eg. when generating
ENTER events before emitting TOUCH_BEGIN).
In these cases clutter_get_current_event() would return NULL after
the inner call to _clutter_process_event() has finished, thereafter
making the current event inaccessible during the remaining portion
of the outer event emission.
By stacking the current events in ClutterMainContext instead of
simply replacing them we do not lose track of the real current event.
Also update clutter_get_current_event_time() to be consistent from a
reentrancy perspective.
https://bugzilla.gnome.org/show_bug.cgi?id=688457
Instead of placing the whole body of the function inside an if block,
let's make it clear what each part of the function does. Also, add more
comments.
GLib 2.36 will deprecate g_type_init() in favour of automatic
initialization through a constructor function. We need to add the
version check to avoid a compiler warning.
When setting an explicit transform with clutter_actor_set_transform()
and a non (0,0) pivot-point, clutter_actor_apply_transform() will fail
to roll back the pivot-point translation done before multiplying the
transformation matrix due to the "out:" label being slightly misplaced
in clutter_actor_real_apply_transform().
This works properly:
clutter_actor_set_pivot_point (actor, 0.5, 0.5);
clutter_actor_set_rotation_angle (actor, CLUTTER_Z_AXIS, 30);
This results in the actor being moved to the pivot-point position:
clutter_actor_set_pivot_point (actor, 0.5, 0.5);
clutter_matrix_init_identity(&matrix);
cogl_matrix_rotate (&matrix, 30, 0, 0, 1.0);
clutter_actor_set_transform (actor, &matrix);
This also add a conformance test checking that even when using a
pivot-point, no matter how a rotation is set the resulting
transformation matrix will be the same.
https://bugzilla.gnome.org/show_bug.cgi?id=690214
clutter_actor_allocate_preferred_size is supposed to use the fixed
position of an actor. Unfortunately, recent refactorings made it so
that it accidentally used the current allocation. As the current
allocation may be adjusted by the actor, or have been previously
allocated in a strange spot, it may have unintended side effects. Use
the fixed positioning of the actor instead.
This fixes weird issues with margins colliding with
ClutterFixedLayout, causing strange offsets on relayout.
https://bugzilla.gnome.org/show_bug.cgi?id=689316
The documentation said that you should return TRUE to mark
that the action was handled, but the code did the reverse.
Change the documentation to reflect what all the other gestures
do.
https://bugzilla.gnome.org/show_bug.cgi?id=689061
Otherwise, we'll have incorrect scrolling when we switch hardware
devices without switching virtual devices. For example, on a ThinkPad,
scroll using the touchpad, move the eraser mouse, and then scroll again:
the deltas will be wrong. This also matches what GTK+ does.
https://bugzilla.gnome.org/show_bug.cgi?id=689258
