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
• Remove the threads_enter/leave calls; they are not needed, given that
the code between init() and main() is single threaded.
• Ensure that the idle callbacks are inserted with the right priority,
to avoid updating the UI after the data has been freed.
Apparently the update to build the GDK backend broke the "installation"
process of the binaries. Fix that by grouping the binaries as Release or
Debug.
Actor transformations do not affect the layout management by default; we
can easily show that a scale animation does not break the layout policy
inside an example.
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.
Unlike gcov, lcov provides a nice HTML output that allows immediate
visualization of the current coverage.
The updates of the build system have been taken from GLib, which has
been using lcov for a while with good results.
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.
