Being able to easily set the number of repeats has been a request for
the animation framework for some time now. The usual way to implement
this is: connect to the ::completed signal, use a static counter, and
stop the timeline when the counter hits a specific spot.
In the same light as the :auto-reverse property, we can make it easier
to implement this common functionality by adding a :repeat-count
property that, when set, limits the amount of loops that a Timeline can
perform before stopping itself.
In fact, we can implement the :loop property in terms of the
:repeat-count property just by using a sentinel value mapping to
"infinity", and map loop=FALSE to repeat-count=0, and loop=TRUE to
repeat-count=-1.
The clutter_timeline_clone() method was a pretty dumb idea when it was
introduced, back when we still had the ClutterEffectTemplate and the
clutter_effect_* animation API. It has since become an API wart: we
cannot change or add new properties to be cloned without the risk of
breaking existing code. All in all, cloning a GObject is just a matter
of calling g_object_new() with the wanted properties.
Let's deprecate this throwback of the Olden Days™, so that we can remove
it for good once we break for 2.0.
When the ClutterTextBuffer support inside ClutterText was merged, it
introduced a regression that was identified and fixed in bug 659116.
The optimization to not paint empty ClutterText actors is only valid
is the actor is not editable, or if the cursor is not visible.
Courtesy of GLib and GTK+. The abicheck.sh is a simple, Linux-only,
script to check that we're not leaking private symbols, or that the
clutter.symbols file hasn't been updated.
In theory, it should go inside the distcheck phase.
A bunch of private symbols have escaped into the SO; let's rectify this
situation by using the '_' private prefix, or making them static as they
should have been.
Cogl now requires that all applications integrate their main loop with
Cogl so that it can listen for events from winsys. This patch just
adds Cogl's GSource to the main loop.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Reviewed-by: Robert Bragg <robert@linux.intel.com>
Some of Cogl's experimental apis have changed so that the buffer apis
now need to be passed a context argument and some drawing apis have been
replaced with cogl_framebuffer_ drawing apis that take explicit
framebuffer and pipeline arguments.
These changes were made as part of Cogl moving towards a more stateless
api that doesn't rely on a global context.
This patch updates Clutter to work with the latest Cogl api and bumps
the required Cogl version to 1.9.5.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Reviewed-by: Neil Roberts <neil@linux.intel.com>
Similar to the clutter_actor_iter_remove(), but it'll call destroy()
instead of remove_child().
We can also reimplement the ::destroy default handler using it, and make
it more compact.
There is a typo in the check for a negative index: the index variable
should be index_, not index - unfortunately, the latter can still be
resolved to index(3), so compiler and linker are perfectly happy.
https://bugzilla.gnome.org/show_bug.cgi?id=669730
An editable ClutterText will reset the selection and cursor whenever the
contents are changed — even if those contents are the same. As this may
confuse the user, we should check if we're setting the exact same string,
and bail out if necessary.
The reverse of position_to_coords().
While providing documentation on how to implement it using the
PangoLayout API, I realized that the verbosity of it all, plus the usage
of the Pango API, was not worth it, and decided to expose the method we
are using internally.
GValueArray is on its way to deprecation in GLib; as far as the
ListModel class is concerned, a plain C array of GValue is a perfectly
suitable replacement for the GValueArray usage. It actually is an
improvement, given that it's going to take less memory.
ClutterActor stopped requiring to override the map and unmap virtual
functions some time ago.
Now that ClutterActor implements the Container interface, overriding map
and unmap to control the MAPPED state of the children is pretty much
going to be a source of bugs and misunderstandings.
Plus, the ordering of the unmap, destroy, dispose, and finalize calls
should be be documented properly.
The documentation should clarify all that.
When calling clutter_actor_destroy(), ClutterActor calls
update_map_state() on itself to unset the REALIZED and MAPPED states,
prior to running the dispose() implementation.
The default dispose() will call remove_child() (either directly or
through the Container implementation), which will check for the MAPPED
state and then run update_map_state() again. We use the previously set
MAPPED state to decide whether or not the parent should queue for a
relayout/redraw when removing a visible children.
If the MAPPED flag was cleared prior to remove_child(), though, it'll
always be unset by the time we get to remove_child(), and this will
cause missing redraws/relayouts; we were ignoring this prior the
post-First Apocalypse changes because we were doing:
if (was_mapped)
clutter_actor_queue_relayout (parent);
clutter_actor_queue_redraw (parent);
which is obviously wrong. Once I removed that glaring brain damage from
the remove_child() implementation, bugs started appearing — bugs that
were probably the reason why we introduced that brain damage in the
first place, instead of checking the source of those bugs.
The obvious fix is to avoid clearing up the actor's state on destroy()
until we remove the actor from its parent. This also reduces the amount
of work we do, and the code paths that can potentially go wrong.
Since the code dealing with ClutterShader is pretty self-contained, now,
we can safely move it outside of the main ClutterActor source file and
into its own. This will allow us to just drop a bunch of files when
branching for 2.0.
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
