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
The X11-specific windowing checks were hidden behind an #ifdef, however
if the tests were run under Wayland, they would execute uncondionally
and cause assertion failures. Fix this by also hiding them behind a
check that the current backend is indeed X11.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The current versions redraws all events on every redraw, which starts
getting very slow quickly. Instead simply draw only the new events
except when the cairo surface got reset, in that case redraw all events
again.
https://bugzilla.gnome.org/show_bug.cgi?id=681584
The CSS3 Transitions specification from the W3C defines the possibility
of using a parametrized step() timing function, with the following
prototype:
steps(n_steps, [ start | end ])
where @n_steps represents the number of steps used to divide an interval
between 0 and 1; the 'start' and 'end' tokens describe whether the value
change should happen at the start of the transition, or at the end.
For instance, the "steps(3, start)" timing function has the following
profile:
1 | x
| |
| x---|
| ' |
| x---' |
| ' |
0 |---' |
Whereas the "steps(3, end)" timing function has the following profile:
1 | x---|
| ' |
| x---' |
| ' |
x---' |
| |
0 | |
Since ClutterTimeline uses an enumeration for controlling the progress
mode, we need additional API to define the parameters of the steps()
progress; for this reason, we need a CLUTTER_STEPS enumeration value,
and a method for setting the number of steps and the value transition
policy.
The CSS3 Transitions spec helpfully also defines a step-start and a
step-end shorthands, which expand to step(1, start) and step(1, end)
respectively; we can provide a CLUTTER_STEP_START and CLUTTER_STEP_END
enumeration values for those.
It can be useful to check whether a ClutterActorIter is currently valid,
i.e. if the iterator has been initialized *and* if the actor to which it
refers to hasn't been updated.
We can also use the is_valid() method in the conformance test suite to
check that initialization has been successful, and that changing the
children list through the ClutterActorIter API leaves the iterator in a
valid state.
For now, it just generates a simple horizontal slide (by writing
to /dev/uinput) and checks that the stage gets the events at the
expected coordinates.
The test won't run if it doesn't have read/write permissions to
/dev/uinput.
It also adds OS_LINUX to config.h.
Instead of going through clutter_event_get_state() and checking if the
modifier mask is set, we can provide simple convenience functions to do
it for us.
The property uses an array with the following CSS style syntax
[ top, right, bottom, left ] or
[ top, left/right, bottom ] or
[ top/bottom, left/right ] or
[ top/right/bottom/left ]
https://bugzilla.gnome.org/show_bug.cgi?id=676367
The bind-constraint.c example still uses clutter_actor_animate(), and
it'd require some serious reworking to move it to
ClutterPropertyTransition or to implicit animations.
This should allow nicer build automation and cross-compilation support.
The former --disable-conformance configure switch has been deprecated by
the --disable-tests one, which is more encompassing as it disables the
whole test suite.
The example code that is meant to be XIncluded into the API reference
should not be part of the interactive test suite: it's code that it is
meant to be used as a reference implementation - whereas the interactive
test suite should be allowed to be lean and test behaviour even in nasty
ways. In short: the test suite should not be the place where we show off
idiomatic code for educational purposes.
The TransitionGroup class is a logical container for running multiple
transitions.
TransitionGroup is not a Score: it is a Transition that advances each
Transition it contains using the delta between frames, and ensures that
all transitions are in a consistent state; these transitions are not
advanced by the master clock.
