The :clip property still uses ClutterGeometry, which is a very bad
rectangle type. Since we cannot change the type of the property
compatibly, we should introduce a new property using ClutterRect
instead. This also matches the ClutterActor.set_clip() API, which uses a
decomposed rectangle with floating point values, like we do with
set_position() and set_size().
Instead of only relying on the (now) deprecated BinAlignment.FIXED
enumeration value, we just ask the actor if a fixed position has been
explicitly set, under the assumption that if a developer decided to call
set_x(), set_y(), or set_position() on an actor inside a BinLayout then
she wanted the fixed position to be honoured.
This removes the last (proper) use of the BinAlignment enumeration.
The Geometry type is an *awful* representation of a integer rectangle,
as it uses unsigned integers for its size, leading to overflow issues
when unioning and intersecting. We have better rectangle types in
Cairo and Clutter, these days.
When dragging/scrolling using touch events, we want the same behaviour
than for motion events. We need to honor the user's calls to
clutter_stage_set_motion_events_enabled() to deactive event
bubbling/captured sequences on the actor located under the pointer and
just transmit events to the stage/grab actor.
https://bugzilla.gnome.org/show_bug.cgi?id=680751
We need to make sure that ClutterActor::transition-stopped is emitted
after the transition was removed from the actor's list of transitions.
We cannot just remove the TransitionClosure from the hash table that
holds the transitions associated to an actor, and let the
TransitionClosure free function stop the timeline, thus emitting the
::transition-stopped signal - otherwise, stopping the timeline will end
up trying to remove the transition from the hash table, and we'll get
either a warning or a segfault.
Since we know we're removing the timeline anyway, we can emit the signal
ourselves in case the timeline is playing, in both the implicit and
explicit cases.
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.
We need an alternative to the translation performed by the anchor point,
one that possibly applies to all three axes and is relative to the
pivot-point.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
For some transformations we need to be able to set the Z component of
the pivot point.
Unlike :pivot-point, the Z coordinate is not normalized because actors
are 2D surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
Given that the rotation transformations are now affected by the pivot
point, the Actor class should provide an accessors pair only for the
angle of rotation on a given axis.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
The pivot point is a point in normalized coordinates space around which
all transformations revolve.
It supercedes the anchor point and the per-transformation center points
as well as the gravity settings, and tries to sort out the mess that
is the modelview matrix set up in ClutterActor.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
The ClutterActor:depth property has always been a bit of a misnomer:
actors are 2D flat surfaces, so they cannot have "depth"; the property
defines the position on the Z axis.
Another side effect of the :depth property is that it decides the
default paint and allocation order on insertion, and that setting it
will call the ClutterContainer.sort_depth_order() method. This has
proven to be a fairly bad design decision that we strung along from the
0.x days, as it gives a false impression of being able to change the
paint and allocation order simply by changing the position on the Z
axis — something that, in reality, requires depth testing to be enabled
during the paint sequence of an actor's parent.
For 2.0 we need a clean break from the side effects, and a better
defined interface.
ClutterActor:z-position is essentially what ClutterActor:depth is, but
doesn't call into ClutterContainer, and has a more apt name.
https://bugzilla.gnome.org/show_bug.cgi?id=679465
The :position property on ClutterText clashes with the same property on
ClutterActor; it's also badly named, given that it represents the
cursor's position inside the text; finally, it does not match its
accessors, violating the API style conventions.
https://bugzilla.gnome.org/show_bug.cgi?id=679457
Overriding the default behaviour of ClutterDragAction::drag-motion is
currently a pain; you either need to subclass the ClutterDragAction and
override the class closure for the signal, or you need to connect to the
signal and call g_signal_stop_emission_by_name() - neither option being
particularly nice or clean. The established pattern for these cases
would be to have a boolean return value on the ::drag-motion signal, but
we cannot do that without breaking ABI.
To solve the issue in a backward compatible way, we should introduce a
new signal, ::drag-progress, with a boolean return value. If the signal
emission chain returns TRUE, the ::drag-motion signal will be emitted,
and the default behaviour will be honoured; if the signal emission chain
returns FALSE, instead, the ::drag-motion signal will not be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=679451
Acquiring the Clutter lock to mark critical sections is not portable,
and not recommended to implement threaded applications with Clutter.
The recommended pattern is to use worker threads, and schedule UI
updates inside idle or timeout handlers within the main loop. We should
enforce this pattern by deprecating the threads_enter()/leave()
functions. For compatibility concerns, we need internal API to acquire
the main lock during frame processing dispatch.
https://bugzilla.gnome.org/show_bug.cgi?id=679450
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.
The dispose sequence will keep the object alive, and we need to release
the last reference held by the StageManager before releasing control to
GObject.
The build should not add deprecated/ into the default INCLUDE paths, so
that deprecated headers are clearly separated; this will make it easier
to get rid of them when we branch out for 2.0.
Copy and paste of the implementation done at Gtk+ based on pango. This
should be moved to a common library, like the old GailTextUtil. Ideally
on pango itself.
https://bugzilla.gnome.org/show_bug.cgi?id=677221
It is possible that we get a DeviceChanged event for a device
that is not in the hash table yet. E.g. I've seen this when
using xrandr to change screen resolution. Prevent a crash in
this case.
https://bugzilla.gnome.org/review?bug=678439
* clutter/clutter-cairo-texture.c (clutter_cairo_texture_emit_draw):
Always update the Cogl texture after emitting ::draw, since we control
the dynamic extent in which drawing should happen on the cairo_t.
Fixes#677966.
If the Interval used has a different type than the property we are
animating through a PropertyTransition then we should transform the
interpolated value before applying it, to avoid warnings down the
line.
The compute() method will cache the result, to avoid multiple
allocations and copies; this means, though, that we need to unset the
GValue when destroying the Interval.
Now that the interval can transform the initial and final values to the
type declared when constructing it, there is no need to check for the
value type inside set_initial_value() and set_final_value().
It's possible that GValues passed to a ClutterInterval setter are not
of the same type as the interval - for instance, if they come from
language bindings, or from untrusted sources; we can use the same
transformation functions we already use inside ClutterTransition to
ensure that the ClutterInterval always stores values of the same type
used to create the interval itself.
The ::stopped signal should be emitted at the end of the Timeline, after
the last ::completed signal emission, in order to have a proper
chronological progress of signal emissions:
started → new-frame → [ ... ] → completed → stopped
This way, ::stopped can perform a proper teardown of the state set up
during ::started, without interfering with the potential cyclical
emission of ::completed.
