BoxLayout will use the easing state of the children it's allocating; the
current API is re-implemented in terms of an implicit easing state
forced on each child prior to allocating it.
Calling clutter_actor_allocate() should transition between the current
allocation and the new allocation, by using the defined implementation
of the easing state.
This means that:
clutter_actor_save_easing_state (actor);
clutter_actor_allocate (actor, &new_alloc, flags);
clutter_actor_restore_easing_state (actor);
will cause "actor" to transition between the current allocation and the
desired new allocation.
The trick is to ensure that this happens without invalidating the
entire actor tree, but only the portion of the tree that has the
transitioned actor as the local root. For this reason, we just call the
allocate() implementation from within the transition frame advancement,
without invalidating flags: the actor, after all, *has* a valid
allocation for the duration of the transition.
The :x-expand and :y-expand flags on ClutterActor are used to signal
that an actor should expand horizontally and/or vertically - i.e. that
its parent's layout management policy should try to assign extra space
to the actor when allocating it.
The expand flags are automatic: when set on a leaf node in the actor
tree, they will bubble up through the parent and grandparents up to the
top level actor; during allocation, the actors with children will lazily
compute whether their children needs to expand.
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.
There are cases when we want to advance a timeline from another time
source. We cannot use _clutter_timeline_do_tick() directly, as that
assumes that the timeline is already playing, so we'll need to create a
wrapper that toggles the playing flag around it.
Given that we can create a ClutterInterval without an initial and final
values using g_object_new(), it stands to reason that we ought to be
able to create an instance when passing NULL GValue pointers to the
new_with_values() constructor as well.
We tend to use float comparison for structured data types like Vertex,
Point, and Size; we should take into consideration fluctuations in the
floating point representation as well.
Instead of a single new() constructor that both allocates and
initializes, split the allocation and initialization into two separate
functions for types that are typically used on the stack, and rarely
allocated on the heap, like ClutterPoint and friends.
This is also applied retroactively to ClutterActorBox and ClutterVertex,
given that the same considerations on usage apply to them as well; we
can add a return value to clutter_actor_box_init() and
clutter_vertex_init() in an ABI-compatible way, so that
clutter_actor_box_new() and clutter_vertex_new() can be effectively
reimplemented as "init (alloc ())".
Using a compound type property for position and size has various
advantages: it reduces the amount of checks; it reduces the amount
of notify signals to connect to; it reduces the amount of transitions
generated.
The ClutterCanvas content implementation should be used instead, to
avoid stringing along the ClutterTexture API and implementation.
This change requires some minor surgery, as the deprecated section
already contains an header for the previously deprecated methods; plus,
we don't want to deprecate clutter_cairo_set_source_color(). This means
creating a new header to be used for Cairo-related API.
The get_distance() API uses machine integers to compute the distance;
this means that on 32bit we can overflow the integer size. This gets
hidden by the fact that get_distance() returns an unsigned integer as
well.
In reality, ClutterPath is an unmitigated mess, and the only way to
actually fix it is to break API.
https://bugzilla.gnome.org/show_bug.cgi?id=652521
This commit adds a further conditional check for calling
clutter_actor_show() when adding a child to an actor. We cannot
unconditionally change the value of the show-on-set-parent property like
the original solution of commit 81b19a78f5
as that breaks the document invariant that show-on-set-parent will be
changed iff an actor is without a parent.
The new ADD_CHILD_SHOW_ON_SET_PARENT flag is part of the default and
legacy flags, thus retaining the default behaviour when adding a child;
the flag is not passed when reordering the list of children, which means
we ignore the state of the show-on-set-parent property.
The conformance test suite fully passes, including the newly added test
to verify that changing the paint order does not trigger visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=674510
This reverts commit 81b19a78f5.
The commit breaks the conformance test unit for the invariants we
guarantee for the 1.x API:
ERROR:actor-invariants.c:307:actor_show_on_set_parent: assertion failed: (show_on_set_parent)
It's possible to run Clutter with the 'null' input backend, which means
that clutter_device_manager_get_default() may return NULL. In the future
we may add a default dummy device manager, but right now it's safer to
just add a simple NULL check in the places where we ask for the device
manager.
