This replaces the 3x3 box blur of ClutterBlurEffect with a two-pass
gaussian blur. The sigma value for the gaussian function (ie, the
bluriness) can be adjusted with a property. The radius for sampling is
limited to ⌈6σ⌉×⌈6σ⌉ as suggested by Wikipedia. The factors for the
sampling are stored in an array in a uniform so the effect only needs
to switch shaders when the sigma jumps to the next radius size. This
makes it feasible to animate the bluriness without depending on
conditional jumps in the shader.

The effect creates a second texture at the same size as the
offscreen's texture to implement the second pass. The effect avoids
redrawing the first pass if the actor is redrawn without being
dirtied. However if the sigma value changes it does need to redraw
both passes but it can still avoid repainting the actual actor.

The two passes share a single shader program with a uniform to
change the direction. The pipelines for each radius are cached in a
hash table attached to the class struct so they can be shared across
multiple instances of the effect.

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>

and getters for sequences and devices of current points. It can be
used for accepting and rejecting sequences for system-wide gestures.

https://bugzilla.gnome.org/show_bug.cgi?id=683090

Don't run the shader and redirect to an FBO if it won't actually do anything.
This saves us on resources a ton.

https://bugzilla.gnome.org/show_bug.cgi?id=683066

There are a couple of debugging messages using XInput 2.2 symbols
unconditionally, and it breaks builds on older systems.

https://bugzilla.gnome.org/show_bug.cgi?id=683219

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

https://bugzilla.gnome.org/show_bug.cgi?id=681648

Andre Kuehne authored Jul 18, 2012 and Emmanuele Bassi committed Aug 27, 2012

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

Emanuele Aina authored Aug 10, 2012 and Emmanuele Bassi committed Aug 27, 2012

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

Emanuele Aina authored Aug 27, 2012 and Emmanuele Bassi committed Aug 27, 2012

Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>

Emanuele Aina authored Aug 27, 2012 and Emmanuele Bassi committed Aug 27, 2012

Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>

https://bugzilla.gnome.org/show_bug.cgi?id=682754

https://bugzilla.gnome.org/show_bug.cgi?id=682795

We need to ensure that the children's cached modelview matrix gets
invalidated when setting the :child-transform property on their parent.

Just like we did for the paint signal; a warning will be emitted if the
diagnostic mode of GLib is enabled through the G_ENABLE_DIAGNOSTIC env
var.

The C4819 warnings appear due to a bug on Visual C++ when running on
non-English locales, specifically CJK versions/locales of Windows.

Re-enable this, like what is done in GLib, and add a note in the
Visual C++ README.txt's to tell people about this, so that Cogl will be
built correctly.

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

Lionel Landwerlin authored Aug 14, 2012 and Emmanuele Bassi committed Aug 20, 2012

https://bugzilla.gnome.org/show_bug.cgi?id=678427