The :transform property controls the modelview matrix of an actor; it
can be used to set a custom modelview matrix on the actor, as opposed
to the decomposed transformations (rotation, scaling, translation)
provided by the ClutterActor class.
The transitions we create implicitly should be removed from the set of
transitions associated to an actor; the transitions explicitly
associated to an actor, though, have to survive the emission of their
'stopped' signal.
We can remove the update_transition() private method, and move its
functionality inside the create_transition() private method, thereby
removing lots of duplicated code, as well as redundant checks on the
existence of a transition. This will allow handling transition updates
atomically in the future.
Another progress function from the CSS3 Transitions specification, using
a parametrices cubic bezier curve between (0, 0) and (1, 1) with two
control points.
(sadly, no ASCII art can approximate a cubic bezier, so no graph)
The cubic-bezier() progress function comes with a bunch of preset easing
modes: ease, ease-in, ease-out, and ease-in-out, that we can map to
enumeration values.
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.
This patch brings 'enter-event' and 'leave-event' generation for touch
based devices. This leads to adding a new API to retrieve coordinates
of a touch point.
https://bugzilla.gnome.org/show_bug.cgi?id=679797
We use floorf() for the allocation origin, and ceilf() for the
allocation size. Swapping the two introduces rounding errors if
the original allocation is not clamped to the nearest pixel.
This reverts commit 7f6b17bc50.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 793bde9143.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 320fb156b4.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 58a1854b57.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 03ec016faa.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
ClutterTexture is full of side effects that have been picked up over the
years; they make improving ClutterTexture harder than necessary, as well
as making subclassing impossible without introducing weird behaviours in
the child classes as well.
Since Clutter 1.10 we have the ClutterImage content type, which is
side-effects free, given that it just paints texture data using the
state of the actor.
Sadly, we still have subclasses of ClutterTexture, both deprecated and
not, so we cannot deprecate ClutterTexture right out; the type and
structures will still be available, like we do for ClutterGroup, but the
whole API should be moved to the deprecated section, waiting for the
time in which we can get rid of it all.
