The YUV support depends on the driver support, and not only not many
drivers support YUV natively: the supported colorspaces are pretty much
useless.
The proper way to do YUV to RGB colorspace conversion on the GPU is to
use a fragment shader; for that, ClutterTexture and Cogl provide enough
API to achieve a good result - see the Clutter-GStreamer implementation,
for instance.
ClutterFixedLayout is the default layout manager for ClutterActor.
Existing subclasses of ClutterActor will get a fixed layout manager
regardless of whether they are going to use it, but since it sets the
CLUTTER_ACTOR_NO_LAYOUT flag, it will introduce regressions on actors
that perform their own layout management.
The CLUTTER_ACTOR_NO_LAYOUT flag was a bit of a mistake in the first
place, as it was introduced as a last minute workaround in the 1.0
process to deal with broken stuff in Moblin. It's going to be a target
for deprecation towards a removal when we start the 2.0 process.
Iterating over children and ancestors of an actor is a relatively common
operation. Currently, you only have one option: start a for() loop, get
the first child of the actor, and advance to the next sibling for the
list of children; or start a for() loop and advance to the parent of the
actor.
These operations can be easily done through the ClutterActor API, but
they all require going through the public API, and performing multiple
type checks on the arguments.
Along with the DOM API, it would be nice to have an ancillary, utility
API that uses an iterator structure to hold the state, and can be
advanced in a loop.
https://bugzilla.gnome.org/show_bug.cgi?id=668669
During the gutting of ClutterBox, the destroy and dispose implementation
were removed. The former, especially, destroyed all children - which
usually meant that the redraw queues for the childre was cleared as
well. The removal introduced crashes when a Box was destroyed while its
children were still queueing redraws.
Symbolic names are better than magic numbers, even if they are
well-established and won't likely change.
This maps to a commit in GTK+ that introduced the same names; it
was decided to go for PRIMARY, MIDDLE, and SECONDARY because of
the confusion that may arise when the button order gets flipped
in left-handed configurations - the "left" button (i.e. 1) becomes
the right-most button, and the "right" button (i.e. 3) becomes
the left-most button.
https://bugzilla.gnome.org/show_bug.cgi?id=668692
Also update the code to set the size of the stage to set it to the size of the
output. In future versions of the Wayland protocol we'll get a configure
message advising of us of the size we can be to achieve fullscreen.
* stage-state:
docs: Update ClutterStageState flags
wayland: Use the Stage state tracking
gdk: Use the Stage state tracking
win32: Use the Stage state tracking
x11: Use the Stage state tracking
osx: Use the Stage state tracking
stage: Add state tracking
State changes on the Stage are currently deferred to the windowing
system backends, but the code is generally the same, and it should
be abstracted neatly inside the Stage class itself.
There's also the extra caveat for backends that state changes on a
Stage must also emit a ClutterEvent of type CLUTTER_STAGE_STATE, a
requirement that needlessly complicates the backend code.
GLib has gained support for compiling ancillary data files into the same
binary blob as a library or as an executable.
We should add this feature to ClutterScript, so that it's possible to
bundle UI definitions with an application.
The only actor that results in a mix of the old Container API and the
new Actor API is ClutterStage. By inheritance, a Stage is a Group, but
we don't want it to behave like a Group - as it already overrides most
of the Actor API, and the reason why it was made as a Group in the
first place was convenience for adding/removing children.
Given that touching Group to make it aware of the new Actor API has
rapidly devolved into a struggle between a Demiurge that tries to
avoid breakage and a Chaos that finds new and interesting ways to
break ClutterGroup, let's declare API bankruptcy here and now.
ClutterStage should override ClutterContainer methods, and use the
layout management of ClutterFixedLayout as the proper class that it
was meant to be ages ago. Let ClutterGroup rot in pieces.
Now that we reinstated Group to its "former glory", we need to ensure
that applications using the deprecated containers with the new DOM API
in ClutterActor can actually work - or, at least, not break horribly.
This actually means making sure that ClutterStage and ClutterGroup can
cope with the DOM, while retaining their old implementations, as well as
their bizarre idiosyncrasies and their utter, utter brokenness.
Making Group just a proxy to Actor broke some behaviour that application
and toolkit code was relying on. Let's keep Group around to fight
another day.
This commit fixes gnome-shell as far as I can test it.
A Group is a just a ClutterActor with the layout-manager property set at
instance initialization time. It doesn't need anything else from
ClutterActor's vtable, except the slightly custom show_all/hide_all
implementation, and a simplified get_paint_volume.
Instead of chaining up, given that we want to bypass chaining up and
just set the allocation. This also allows us to bail out of the
overridden allocate vfunc check, given that we want the default Actor
behaviour to apply - including eventual layout manager delegates.
The usual way to implement a container actor is to override the
allocate() virtual function, chain up, and then allocate the actor's
children.
Clutter now has the ability to delegate layout management to
ClutterLayoutManager directly; in the allocation, this is done by
checking whether the actor has children, and then call
clutter_layout_manager_allocate() from within the default implementation
of the ClutterActor::allocate() vfunc. The same vfunc that everyone, has
been chaining up to.
Whoopsie.
Well, we can check if there's a layout manager, and if it's NULL, we
bail out. Except that there's a default layout manager, and it's the
fixed layout manager, so that classes like Group and Stage work by
default.
Double whoopsie.
The fix for this scenario is a bit nasty; we have to check if the actor
class has overridden the allocate() vfunc or not, before actually
looking at the layout manager. This means that classes that override the
allocate() vfunc are expected to do everything that ClutterActor's
default implementation does - which I think it's a fair requirement to
have.
For newly written code, though, it would probably be best if we just
provided a function that does the right thing by default, and that
you're supposed to be calling from within the allocate() vfunc
implementation, if you ever chose to override it. This new function,
clutter_actor_set_allocation(), should come with a warning the size of
Texas, to avoid people thinking it's a way to override the whole "call
allocate() on each child" mechanism. Plus, it should check if we're
inside an allocation sequence, and bail out if not.
