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
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.
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
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
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
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.
The animation tutorial was written in the Good Ol' 0.x days, and has
barely been updated during the 1.x cycle; it only referenced low level
or deprecated API, and the ClutterActor class description has a whole
section on how to animate actors using both the implicit and the
explicit animation API.
ClutterContent implementations may allow repeating their contents when
painting; we should provide the repeat policy on the actor, like we do
for scaling filters and content gravity.
ClutterGridLayout is port of GtkGrid to a Clutter layout manager. All
the logic is taken from gtkgrid.c, so all the credits should go to
Matthias Clasen for writing this nice piece of code.
ClutterGridLayout supports adding children with it's own methods
GridLayout.attach() and GridLayout.attach_next_to() as well as
Actor.add_child() and friends. The latter adds children in a similar
fashion to ClutterBoxLayout
https://bugzilla.gnome.org/show_bug.cgi?id=677372
The plain C bytes array, while convenient from a C perspective, is not
well handled by language bindings: the length of the array is not
specified, and it's only just implied by the image data size, rowstride,
and pixel format.
GBytes is a read-only bytes buffer that has an implicit length; we can
use it as the storage medium so that language bindings can actually
function correctly.
It's similar to to the implicit animation API of ClutterActor and
compatible to deprecated API of ClutterBoxLayout and
ClutterTableLayout.
It adds :use-animations, :easing-mode, :easing-duration and
:easing-delay properties to control animations when allocation of a
child has changed. Layout manager implementers should call
use_animations = clutter_layout_manager_get_easing_state (manager,
&mode,
&duration,
&delay);
from the allocate() virtual function to access these values.
https://bugzilla.gnome.org/show_bug.cgi?id=676827
Instead of going through clutter_event_get_state() and checking if the
modifier mask is set, we can provide simple convenience functions to do
it for us.
The TransitionGroup class is a logical container for running multiple
transitions.
TransitionGroup is not a Score: it is a Transition that advances each
Transition it contains using the delta between frames, and ensures that
all transitions are in a consistent state; these transitions are not
advanced by the master clock.
At least for the time being, we only expose the parts of the API that we
want to use internally and for new, out-of-tree Content implementations.
The full PaintNode tree API will be made public in 1.12 once we branch
master.
ClutterActor should be able to hold all transitions, even the ones that
have been explicitly created.
This will allow to add new transitions types in the future, like the
keyframe-based one, or the transition group.
It should be possible to ask a timeline what is its duration, taking
into account eventual repeats, and which repeat is the one currently
in progress.
These two functions allow writing animations that depend on the current
state of another timeline.
It should be possible to set up the delay of a transition, but since
we start the Transition instance before returning control to the caller,
we cannot use clutter_actor_get_transition() to do it without something
extra-awkward, like:
transition = clutter_actor_get_transition (actor, "width");
clutter_timeline_stop (transition);
clutter_timeline_set_delay (transition, 1000);
clutter_timeline_start (transition);
for each property involved. It's much easier to add a delay to the
easing state of an actor.
The ClutterBrightnessContrastEffect effect class allows changing the
brightness and contrast levels of an actor.
Modified-by: Emmanuele Bassi <ebassi@linux.intel.com>
Modified-by: Neil Roberts <neil@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=656156
It is sometimes useful to be able to have better control on when a
repaint function is called. Currently, all repaint functions are called
prior to the stages update phase of the frame processing.
We can introduce flags to represent the point in the frame update
process in which we wish Clutter called the repaint function.
As a bonus, we can also add a flag that causes adding a repaint function
to spin the master clock.
This adds a virtual function to ClutterInputDevice to translate a
keycode from the hardware_keycode member of ClutterKeyEvent to an
evdev keycode. The function can fail so that input backends that don't
have a sensible way to translate to evdev keycodes can return FALSE.
There are implementations for evdev, wayland and X. The X
implementation assumes that the X server is using an evdev driver in
which case the hardware keycodes are the evdev codes plus 8.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
Now that ClutterActor has a default paint volume, subclasses may wish
to retrieve it without chaining up to the parent's implementation of
the get_paint_volume() function.
The get_default_paint_volume() returns a ClutterPaintVolume pointer
to the paint volume as computed by the default implementation of the
get_paint_volume() virtual function; it can only be used immediately,
as it's not guaranteed to survive across multiple frames.
Creating PaintVolume instances is not possible, and it's not recommended
anyway. It is, though, necessary to union paint volumes, especially with
2D boxes, in some cases.
Clutter should provide a simple convenience function that allows
unioning volumes to boxes in a moderately efficient way.
https://bugzilla.gnome.org/show_bug.cgi?id=670021
Sometimes a subclass of ClutterOffscreenEffect wants to paint with a
completely custom material. In that case it is awkward to modify the
material returned owned by ClutterOffscreenEffect so it makes more
sense to just get the texture and manage its own material.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
There are times when we don't want to remove all children and count of
the reference count to drop to 0 to ensure destruction; there are cases,
such as managed environments, where it's preferable to ensure that the
children of an actor get actually destroyed.
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 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.
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
Given the size and scope of the changes in ClutterActor, we ought to
rewrite the overall description of what an actor is, what it does, and
how are you supposed to use it and subclass it.
This adds a --enable-wayland-compositor configure option which will add
support for a ClutterWaylandSurface actor which can be used to aid in
writing Wayland compositors using Clutter by providing a ClutterActor to
represent Wayland client surfaces.
Notably this configure option isn't tied into any particular backend
since conceptually the compositor support can be used in conjunction
with any clutter backend that has corresponding Cogl support.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
This updates Wayland support in line with upstream changes to the Wayland
API and protocol.
This update means we no longer use the Cogl stub winsys so a lot of code
that had to manually interact with EGL and implement a swap_buffers
mechanism could be removed and instead we now depend on Cogl to handle
those things for us.
This update also adds an input device manager consistent with other
clutter backends.
Note: to use the client side "wayland" clutter backend you need to have
built Cogl with --enable-wayland-egl-platform. If Cogl has been built
with support for multiple winsys backends then you should run
applications with COGL_RENDERER=EGL in the environment.
Reviewed-by: Emmanuele Bassi <ebassi@linux.intel.com>
* deprecate-default-stage:
evdev: do not associate device with stage
evdev: don't even process events without a default stage
docs: Note default stage deprecation in README
docs: Remove clutter_stage_get_default()
stage: Deprecate the default stage
script: Do not use clutter_stage_get_default()
cally/actor: Do not use the default stage as a fallback
Try to mop up the default stage mess
performance/*: Do not use clutter_stage_get_default()
interactive/*: Do not use clutter_stage_get_default()
Merge with a11y
micro-bench/*: Do not use clutter_stage_get_default()
accessibility/*: Do not use clutter_stage_get_default()
conform/*: Do not use clutter_stage_get_default()
A lot of the example code in the cookbook and the API reference still
uses the default stage — sometimes as if it were a non-default one,
which once again demonstrates how the default stage was a flawed concept
that just confused people.
