ClutterActor provides four methods for changing the paint sequence order
of its children:
raise_top()
raise()
lower()
lower_bottom()
The first and last one being just wrappers around raise() and lower(),
respectively. These methods have various issues: they omit the parent,
preferring to retrieve it from the actor passed as the first argument;
this does not match the new style of API introduced to operate on the
list of children of an actor.
Additionally, the raise() and lower() methods of ClutterActor call into
the Container interface, and are not really aptly named (raise() in
particular collides with the completely unrelated 'raise' keyword in
Python, and usually needs to be wrapped in order to be used at all).
Furthermore, we need public methods that Container can call from its
default implementation, as well as methods to port current Container
implementations.
Finally, since we have insert_child_at_index(), we should also have an
equivalent set_child_at_index() as well.
The correct sequence of actions should be remove(old) → insert(new), not
insert(new) → remove(old). We can implement a simple delegate insertion
functions to insert the new child between the previous and next siblings
of the old child.
While we're at it, let's also add a unit test for replace_child().
Verify that insertion and removal maintain a stable graph, with pointers
to the various children. This should help out tracking regressions in
the scene graph API.
ClutterActor now has all the API and capabilities for being a concrete
class:
- layout management, through delegation
- container implementation and API
- background color
This means that a simple scene can be built straight out of actors
without using subclasses except for the Stage.
This is the first step towards the deprecation of most of the Actor
subclasses provided by Clutter.
The minimum preferred size of a Flow layout manager is the size of a
column or a row, as the whole point of the layout policy enforced by
the Flow layout manager is to reflow when needed.
And make sure that overriding Container and calling
clutter_actor_add_child() will result in the same sequence of operations
as the current set_parent()+queue_relayout()+signal_emit pattern.
Existing containers can continue using:
clutter_actor_set_parent (child, CLUTTER_ACTOR (container));
clutter_actor_queue_relayout (CLUTTER_ACTOR (container));
g_signal_emit_by_name (container, "actor-added", child);
and newly written containers overriding Container.add() can simply call:
clutter_actor_add_child (CLUTTER_ACTOR (container), child);
instead.
This adds an extremely minimal wayland compositor to tests/interactive
to test the ClutterWaylandSurface actor. Currently this minimal
compositor doesn't support any input, it simply paints client surfaces
fixed at the top-left of the stage.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
The coordinate transformation code is exercised throughout the
conformance and interactive tests, so there's no need to have a specific
interactive test that doesn't do anything more complicated than calling
clutter_actor_transform_stage_point().
Even if the test has been successfully compiled against the X11 backend,
we need to ensure that it is actually running against it, otherwise bad
things will happen.
The Clutter backend split is opaque enough that should allow us to just
build all possible backends inside the same shared object, and select
the wanted backend at initialization time.
This requires some work in the build system, as well as the
initialization code, to remove duplicate functions that might cause
conflicts at build and link time. We also need to defer all the checks
of the internal state of the platform-specific API to run-time type
checks.
This commit introduces a new flavour for Clutter, that uses GDK
for handling all window system specific interactions (except for
creating the cogl context, as cogl does not know about GDK), including
in particular events. This is not compatible with the X11 (glx)
flavour, and this is reflected by the different soname (libclutter-gdk-1.0.so),
as all X11 specific functions and classes are not available. If you
wish to be compatible, you should check for CLUTTER_WINDOWING_X11.
Other than that, this backend should be on feature parity with X11,
including XInput 2, XSettings and EMWH (with much, much less code)
https://bugzilla.gnome.org/show_bug.cgi?id=657434