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.
