When trying to clamp to pixel a box that is exactly in between 2
pixels, the clutter_actor_box_clamp_to_pixel() function changes the
size of the box.
Here is an example :
ClutterActorBox box = { 10.5, 10, 20.5, 20};
g_message ("%fx%f -> %fx%f", box.x1, box.y1, box.x2, box.y2);
clutter_actor_box_clamp_to_pixel (&box);
g_message ("%fx%f -> %fx%f", box.x1, box.y1, box.x2, box.y2);
Here is what you get :
** Message: 10.500000x10.000000 -> 20.500000x20.000000
** Message: 10.000000x10.000000 -> 21.000000x20.000000
That is because of the properties of the ceilf and floorf function
used to do the clamping.
For example, ceil(0.5) is 1.0, and ceil(-0.5) is 0.0.
And, floor(0.5) is 0.0, and floor(-0.5) is -1.0.
To work around that problem this patch retains the distance between x
and y coordinates and apply that difference before calling ceilf() on
x2 and y2.
https://bugzilla.gnome.org/show_bug.cgi?id=689073
Export the last event received for each touch point in its entirety,
instead of duplicating ClutterEvent accessors one at a time.
examples/pan-action.c has been updated to show the type of the event
that's causing the panning.
https://bugzilla.gnome.org/show_bug.cgi?id=685737
TapAction is a GestureAction-subclass that handles clicks and
tap gestures. It is meant to provide a replacement for ClickAction
using GestureAction:
• it handles events trasparently without capturing them, so that it
can coexists with other GestureActions;
• the ::tap signal is not emitted if the drag threshold is exceeded;
• building upon GestureAction the amount of code is greatly reduced.
TapAction provides:
• tap signal, notifying users when a tap has been performed.
The image-content example program has been updated replacing its
ClickAction usage with TapAction.
https://bugzilla.gnome.org/show_bug.cgi?id=683948
Ensure that when cancelling a gesture, either because a callback
has returned FALSE or because clutter_gesture_action_cancel() has
been called, the array tracking touch points is emptied and a whole
new set of touch points is needed before restarting the gesture.
https://bugzilla.gnome.org/show_bug.cgi?id=685221
Let gesture subclasses override how the drag threshold should
be handled:
• CLUTTER_GESTURE_TRIGGER_NONE tells GestureAction that the gesture
must begin immediately and there's no drag limit that will cause
its cancellation;
• CLUTTER_GESTURE_TRIGGER_AFTER is the default GestureAction behaviour,
where it needs to wait until the drag threshold has been exceeded
before considering the gesture valid;
• CLUTTER_GESTURE_TRIGGER_BEFORE will make GestureAction cancel
the gesture once the drag exceed the configured threshold.
For example, ZoomAction and RotateAction could set
CLUTTER_GESTURE_TRIGGER_NONE since the use of two fingers makes the
begin of the action more self-evident, while an hypothetical Tap
gesture may use CLUTTER_GESTURE_TRIGGER_BEFORE to cancel the tap if
the pointer moves too much.
https://bugzilla.gnome.org/show_bug.cgi?id=685028
The code for handling key repeats (and in particular stopping on focus loss)
assumes that the repeat key is set to XKB_KEYCODE_INVALID in the default case.
This change switches to the new mechanism for loading a cursor into a buffer.
It no longer relies on having a PNG stored in a known location and instead
loads from the Wayland cursor theme.
Signed-off-by: Rob Bradford <rob@linux.intel.com>
Add support for repeating keys to the Wayland input backend.
Unfortunately the repeat delay/interval is hardcoded into the Clutter
backend, as Wayland doesn't yet tell clients what the global values
should be.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
For Wayland, this is mostly the input protocol having changed, although
there's also the SHM pool API, the cursor API, as well as fullscreen and
ping.
Also port to the new (months-old) xkbcommon API, as used by Weston 0.95.
This involves having xkbcommon manage the state for us, where
appropriate. Fans of multi-layout keyboards (or just caps lock) will no
doubt appreciate these changes.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Looks like we need to include this directly, but also need to include
cogl/cogl.h to get COGL_HAS_EGL_SUPPORT, since cogl-egl.h doesn't
include cogl-defines.h first.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If a button press happen on stage and the pointer is moved outside
the stage while holding the mouse button, the motion and release
events are still delivered to actors. Do the same X11 soft grab
emulation for touch events.
https://bugzilla.gnome.org/show_bug.cgi?id=685589
On various systems, trying to release a mutex that hasn't been acquired
will result in a run-time error.
In order to avoid this, we trylock() the Big Clutter Lock™ and
immediately unlock() it, regardless of the result; if the lock was
already acquired, trylock() will immediately fail, and we can release
it; if the lock was not acquired, trylock() will succeed, and we can
release the lock immediately.
This is necessary to maintain binary compatibility and invariants for
Clutter applications doing:
clutter_init()
clutter_threads_enter()
...
clutter_main()
...
clutter_threads_leave()
instead of the correct:
clutter_init()
clutter_threads_enter()
...
clutter_threads_leave()
clutter_main()
clutter_threads_enter()
...
clutter_threads_leave()
With Clutter ≥ 1.12, the idiomatic form is:
clutter_init()
...
clutter_main()
given that the public Big Clutter Lock™ acquire/release API has been
deprecated, and nobody should take the lock outside of Clutter itself.
https://bugzilla.gnome.org/show_bug.cgi?id=679439
When the last touch has been released the stage on the
corresponding master device (eg. the virtual core pointer) is set
to NULL and no mouse events can be delivered until an ENTER event
has occurred and the stage pointer restored.
This is due to the fact that the master devices can send both
touch events and mouse events, forwarding events coming from the
attached slave devices.
To restore delivery of mouse events we need to ensure that the
stage is set on each ButtonPress, ButtonRelease and Motion event
coming from master devices.
https://bugzilla.gnome.org/show_bug.cgi?id=684509
When using the new ActorAlign flags we must get the real alignment for
the horizontal axis, as clutter_actor_allocate() will compute the
effective alignment by itself; if we use the effective alignment then
ClutterActor.allocate() will swap it, and undo our work.
When using the old BinAlignment flags we should reverse the alignment
depending on whether the text direction of the child is RTL or LTR.
See bug: https://bugzilla.gnome.org/show_bug.cgi?id=684214
It should be possible to destroy the actor currently being dragged from
within the ::drag-end signal. In order to do this, we need to keep a
reference on the action for the duration of the emit_drag_end() function
as well as resetting the action's state inside the dispose()
implementation, to avoid trying to access cleared data.
https://bugzilla.gnome.org/show_bug.cgi?id=681814
Modified Return key presses don't trigger ::activate so we would end
up adding an unprintable character to a single paragraph mode pango
layout which renders it as a box.
https://bugzilla.gnome.org/show_bug.cgi?id=623344
The code for calculating the content box when the aspect ratio is
greater than 1 was broken. The same code that did the calculation for
aspect ratio less than 1 should be used in all cases.
Fixes: https://bugzilla.gnome.org/682161
When we miss button release events (eg. when they happen outside
of our window) we must ensure that the corresponding point is
removed from the array of tracked points, otherwise GestureAction
will get very confused and will cancel all subsequent gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=683471
When starting a new gesture before the momentum of the previous one
has finished the ::pan-stopped was counter-intuitively emitted
after the new ::gesture-begin.
Make use of gesture_prepare() to reset the state of the action
right before emitting ::gesture-begin.
https://bugzilla.gnome.org/show_bug.cgi?id=683431
We often mean that when key_focus == NULL, it's assumed to be on the
stage, and clutter_stage_get_key_focus() reflects this. We also do a
lot of check around the lines of key_focus == NULL instead of also
checking for the stage, so make sure to normalize it so that explicitly
grabbing the stage's key focus will not change our behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=683301
The ClutterEventSequence structure is a fully opaque type; on X11, it is
just an unsigned integer that gets converted into a pointer, but in the
future it may become a fully fledged data structure.
Obviously, we cannot tell people to just dereference the pointer into an
integer in order to use it, and still retain the ability to change the
type; for this reason, we need a proper accessor function to convert the
EventSequence into a touch detail, to be used with the XInput API.
The ordering of the evdev button numbers is the opposite of the
order in Clutter (the middle button is 3 instead of 2) so we need to
manually map the button numbers when creating a ClutterButtonEvent.
https://bugzilla.gnome.org/show_bug.cgi?id=680255
803b3bafb6 introduced a new issue for
multi touch events.
In the case where 2 touch events for 2 different touch points are
processed in the same iteration, a call to
_clutter_stage_remove_device() when processing the first event will
remove the stage setting of the InputDevice. That means Clutter will
skip the second event, because it can't find a stage to which relate
the event, so no related actor and so no emission.
To fix this we move the _clutter_stage_(add/remove)_device() calls
into the input device. This way the input device can find out exactly
when to call these functions (i.e. when no touch point were previously
active or when no touch point remain active).
https://bugzilla.gnome.org/show_bug.cgi?id=682362
Interpolating between two transformations expressed using a 3D matrix
can be achieved by decomposing the matrices into their transformations
and do a simple numeric interpolation between the initial and final
states, like we do for other data types.
Luckily for us, the CSS Transforms specification from the W3C provides
the decomposition algorithm, using the "unmatrix" code taken from the
book "Graphics Gems II, edited by Jim Arvo".
Once the matrices have been decomposed, we can simply interpolate the
transformations, and re-apply them onto the result matrix, using the
facilities that Clutter provides for interpolating between two known
GTypes.
Since Cogl version 1.11.2, Cogl no longer includes the EGL headers
from cogl.h if COGL_ENABLE_EXPERIMENTAL_2_0_API is defined. Instead
the application needs to include cogl-egl.h so that we can avoid
polluting the global namespace with X defines. Clutter defines the 2.0
define in its configure.ac and it is relying on Cogl to include the
right EGL header in clutter-egl-headers.h so we need to change which
header it includes.
When changing an implicit transition mid flight we may end up with an
easing state with a duration of zero milliseconds; this leads to the
implicit transition machinery setting the final state directly onto the
actor. If there is a running transition, though, we need to remove it
from the transitions table, otherwise it will keep running.
This regression happened when the update_transition() internal function
was merged into the create_transition() one.
Tested-by: Lionel Landwerlin <llandwerlin@gmail.com>
PanAction is a GestureAction-subclass that implements the panning
concept for scrollable actors, with the ability to emit interpolated
signals to emulate the kinetic inertia of the panning. PanAction provides:
• pan signal, notifying users of the panning gesture status;
• pan-stopped signal, emitted at the end of the interpolated phase
of the panning gesture, if enabled;
• pan-axis property, to allow constraining the dragging to a specific
axis;
• interpolated property, to enable or disable the inertial behaviour;
• deceleration property, to customize the rate at which the momentum
of the panning will be slowed down;
• acceleration-factor property, applied to the inertial momentum when
starting the interpolated sequence.
An interactive test is also provided.
https://bugzilla.gnome.org/show_bug.cgi?id=681648
Add some accessors to simplify common tasks for GestureAction users:
• clutter_gesture_action_get_motion_delta() to get the delta
on the X and Y axis in stage coordinates since the last motion
event, and the scalar distance travelled;
• clutter_gesture_action_get_velocity() to get an estimate of the
speed of the last motion event along the X and Y axis and as a
scalar value in pixels per millisecond.
https://bugzilla.gnome.org/show_bug.cgi?id=681648
When appending (with a negative row/column parameter), the row/column
count should be incremented by 1, not 2. This also fixes layout errors
when using column/row spacing: The amount of extra space required was
calculated incorrectly due to the wrong column count.
https://bugzilla.gnome.org/show_bug.cgi?id=679990
When setting a drag handle, transform the original press
coordinates using the drag handle as reference instead of the
associated actor.
This causes the initial misplacement of drag handle in
example/drag-action when holding down the Shift key: the handle
gets placed at the main actor origin on the first drag event,
instead of following the mouse pointer.
All subsequent motion events already use the right actor when
transforming the coordinates, thus they are not affected.
https://bugzilla.gnome.org/show_bug.cgi?id=681746
If the DragAction has a drag handle that gets destroyed inside the
::drag-end signal handler, the destruction sequence will trigger a
callback we have in place to check if the handle is being destroyed
mid-drag, e.g. from a ::drag-motion event.
The callback on the drag handle destruction will check if we are still
in the middle of a drag and emit the ::drag-end signal to allow cleaning
up; the callback erroneously uses the drag handle as the argument for
the emit_drag_end() function — instead of the actor to which the drag
action has been attached. Also, by the time we emit the ::drag-end, we
are not dragging the actor any more, so we shouldn't be emitted the
::drag-end signal twice.
The fix is, thus, made of two parts:
- reset the in_drag boolean before emitting the ::drag-end signal
so that destroying the drag handle will not result in a double
signal emission;
- use the correct actor when calling emit_drag_end().
https://bugzilla.gnome.org/show_bug.cgi?id=681814
If the actor has a fixed position set, but it's not using the BinLayout
alignment enumeration to set its alignment, then we force the alignment
factor to 0.0; this is consistent with what happens with an explicit
alignment of CLUTTER_BIN_ALIGNMENT_FIXED.
https://bugzilla.gnome.org/show_bug.cgi?id=682265
Event handling should only apply to editable ClutterText actors, but we
also have the :selectable property to care about.
The button/touch press should position the cursor inside an editable
ClutterText; the :selectable property should be used to allow selecting
the text, either through pointer or touch dragging, via the keyboard, or
by multiple pointer clicks. If neither of these two conditions are met,
the ClutterText should just propagate the event handling further.
Allow setting a ClutterRect on the drag action and force the
dragged actor's position to be always within that rectangle (relative
to the actor's parent).
https://bugzilla.gnome.org/show_bug.cgi?id=681168
The boolean_handled accumulator will stop the signal emission if TRUE is
returned by a signal handler; the boolean_continue accumulator will stop
the signal emission if FALSE is returned. The first one is used for
event-related signals, while the latter is used for action-related
signals.
Only the signal connection. When using G_ENABLE_DIAGNOSTIC there will be
a warning for every signal connection.
We should try and discourage people from ever using the paint signal
ever again, until we can safely remove it in Clutter 2.0.
We cannot fully deprecate Geometry, because ClutterActor and ClutterText
are actually using the type in signals and properties; but we can
deprecate the API that uses this type, so that 2.0 will be able to avoid
it entirely.
The :clip property still uses ClutterGeometry, which is a very bad
rectangle type. Since we cannot change the type of the property
compatibly, we should introduce a new property using ClutterRect
instead. This also matches the ClutterActor.set_clip() API, which uses a
decomposed rectangle with floating point values, like we do with
set_position() and set_size().
Instead of only relying on the (now) deprecated BinAlignment.FIXED
enumeration value, we just ask the actor if a fixed position has been
explicitly set, under the assumption that if a developer decided to call
set_x(), set_y(), or set_position() on an actor inside a BinLayout then
she wanted the fixed position to be honoured.
This removes the last (proper) use of the BinAlignment enumeration.
The Geometry type is an *awful* representation of a integer rectangle,
as it uses unsigned integers for its size, leading to overflow issues
when unioning and intersecting. We have better rectangle types in
Cairo and Clutter, these days.
When dragging/scrolling using touch events, we want the same behaviour
than for motion events. We need to honor the user's calls to
clutter_stage_set_motion_events_enabled() to deactive event
bubbling/captured sequences on the actor located under the pointer and
just transmit events to the stage/grab actor.
https://bugzilla.gnome.org/show_bug.cgi?id=680751
We need to make sure that ClutterActor::transition-stopped is emitted
after the transition was removed from the actor's list of transitions.
We cannot just remove the TransitionClosure from the hash table that
holds the transitions associated to an actor, and let the
TransitionClosure free function stop the timeline, thus emitting the
::transition-stopped signal - otherwise, stopping the timeline will end
up trying to remove the transition from the hash table, and we'll get
either a warning or a segfault.
Since we know we're removing the timeline anyway, we can emit the signal
ourselves in case the timeline is playing, in both the implicit and
explicit cases.
The :transform property controls the modelview matrix of an actor; it
can be used to set a custom modelview matrix on the actor, as opposed
to the decomposed transformations (rotation, scaling, translation)
provided by the ClutterActor class.
The transitions we create implicitly should be removed from the set of
transitions associated to an actor; the transitions explicitly
associated to an actor, though, have to survive the emission of their
'stopped' signal.
We can remove the update_transition() private method, and move its
functionality inside the create_transition() private method, thereby
removing lots of duplicated code, as well as redundant checks on the
existence of a transition. This will allow handling transition updates
atomically in the future.
Another progress function from the CSS3 Transitions specification, using
a parametrices cubic bezier curve between (0, 0) and (1, 1) with two
control points.
(sadly, no ASCII art can approximate a cubic bezier, so no graph)
The cubic-bezier() progress function comes with a bunch of preset easing
modes: ease, ease-in, ease-out, and ease-in-out, that we can map to
enumeration values.
The CSS3 Transitions specification from the W3C defines the possibility
of using a parametrized step() timing function, with the following
prototype:
steps(n_steps, [ start | end ])
where @n_steps represents the number of steps used to divide an interval
between 0 and 1; the 'start' and 'end' tokens describe whether the value
change should happen at the start of the transition, or at the end.
For instance, the "steps(3, start)" timing function has the following
profile:
1 | x
| |
| x---|
| ' |
| x---' |
| ' |
0 |---' |
Whereas the "steps(3, end)" timing function has the following profile:
1 | x---|
| ' |
| x---' |
| ' |
x---' |
| |
0 | |
Since ClutterTimeline uses an enumeration for controlling the progress
mode, we need additional API to define the parameters of the steps()
progress; for this reason, we need a CLUTTER_STEPS enumeration value,
and a method for setting the number of steps and the value transition
policy.
The CSS3 Transitions spec helpfully also defines a step-start and a
step-end shorthands, which expand to step(1, start) and step(1, end)
respectively; we can provide a CLUTTER_STEP_START and CLUTTER_STEP_END
enumeration values for those.
This patch brings 'enter-event' and 'leave-event' generation for touch
based devices. This leads to adding a new API to retrieve coordinates
of a touch point.
https://bugzilla.gnome.org/show_bug.cgi?id=679797
We use floorf() for the allocation origin, and ceilf() for the
allocation size. Swapping the two introduces rounding errors if
the original allocation is not clamped to the nearest pixel.
This reverts commit 7f6b17bc50.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 793bde9143.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 320fb156b4.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 58a1854b57.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
This reverts commit 03ec016faa.
ClutterLayoutManager implementations should just defer the easing state
set up to the child, and not try to impose a global one.
ClutterTexture is full of side effects that have been picked up over the
years; they make improving ClutterTexture harder than necessary, as well
as making subclassing impossible without introducing weird behaviours in
the child classes as well.
Since Clutter 1.10 we have the ClutterImage content type, which is
side-effects free, given that it just paints texture data using the
state of the actor.
Sadly, we still have subclasses of ClutterTexture, both deprecated and
not, so we cannot deprecate ClutterTexture right out; the type and
structures will still be available, like we do for ClutterGroup, but the
whole API should be moved to the deprecated section, waiting for the
time in which we can get rid of it all.
We need an alternative to the translation performed by the anchor point,
one that possibly applies to all three axes and is relative to the
pivot-point.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
For some transformations we need to be able to set the Z component of
the pivot point.
Unlike :pivot-point, the Z coordinate is not normalized because actors
are 2D surfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
Given that the rotation transformations are now affected by the pivot
point, the Actor class should provide an accessors pair only for the
angle of rotation on a given axis.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
The pivot point is a point in normalized coordinates space around which
all transformations revolve.
It supercedes the anchor point and the per-transformation center points
as well as the gravity settings, and tries to sort out the mess that
is the modelview matrix set up in ClutterActor.
https://bugzilla.gnome.org/show_bug.cgi?id=677853
The ClutterActor:depth property has always been a bit of a misnomer:
actors are 2D flat surfaces, so they cannot have "depth"; the property
defines the position on the Z axis.
Another side effect of the :depth property is that it decides the
default paint and allocation order on insertion, and that setting it
will call the ClutterContainer.sort_depth_order() method. This has
proven to be a fairly bad design decision that we strung along from the
0.x days, as it gives a false impression of being able to change the
paint and allocation order simply by changing the position on the Z
axis — something that, in reality, requires depth testing to be enabled
during the paint sequence of an actor's parent.
For 2.0 we need a clean break from the side effects, and a better
defined interface.
ClutterActor:z-position is essentially what ClutterActor:depth is, but
doesn't call into ClutterContainer, and has a more apt name.
https://bugzilla.gnome.org/show_bug.cgi?id=679465
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
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.
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.
Now that the interval can transform the initial and final values to the
type declared when constructing it, there is no need to check for the
value type inside set_initial_value() and set_final_value().
It's possible that GValues passed to a ClutterInterval setter are not
of the same type as the interval - for instance, if they come from
language bindings, or from untrusted sources; we can use the same
transformation functions we already use inside ClutterTransition to
ensure that the ClutterInterval always stores values of the same type
used to create the interval itself.
The ::stopped signal should be emitted at the end of the Timeline, after
the last ::completed signal emission, in order to have a proper
chronological progress of signal emissions:
started → new-frame → [ ... ] → completed → stopped
This way, ::stopped can perform a proper teardown of the state set up
during ::started, without interfering with the potential cyclical
emission of ::completed.
Calling clutter_point_free(clutter_point_zero()) or calling
clutter_rect_free(clutter_rect_zero()) should be safe, exactly like it's
safe to call those functions with a NULL argument.
The implicit animations only apply to properties that are documented as
'animatable'; the explicit animations apply to any property defined
through GObject or ClutterAnimatable.
For 1.x, we still have a duration of 0 msecs, but we have a valid easing
state, so we can change the easing parameters without calling save and
restore.
By checking if the interval is valid inside compute_value() we can catch
the cases where the interval values of a PropertyTransition are set
after the transition has been added to an Animatable instance - i.e. the
following code:
let transition = new Clutter.PropertyTransition();
transition.set_property_name('opacity');
actor.add_transition('opacityAnim', transition);
transition.set_to_value(0);
should be equivalent to:
let transition = new Clutter.PropertyTransition();
transition.set_property_name('opacity');
transition.set_to_value(0);
actor.add_transition('opacityAnim', transition);
instead of emitting a warning.
Once a ClutterPropertyTransition is attached to a ClutterAnimatable, if
no interval is set we can simply use the current state of the property
to define the from and to values. This allows the creation of property
transitions from the current state of the Animatable instance without
excessive verbosity.
