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
ClutterDragAction should be able to use the newly added ClutterSettings
property exposing the system's drag threshold.
Currently, the x-drag-threshold and the y-drag-threshold properties (and
relative accessors) use an unsigned integer for their values; we should
be able to safely expand the range to include -1 as the minimum value,
and use this new value to tell the ClutterDragAction that it should query
the ClutterSettings object for the drag threshold.
The storage of the properties has been changed, albeit in a compatible
way, as GObject installs a uint ↔ int transformation function for GValue
automatically.
The setter for the drag thresholds has been changes to use a signed
integer, but the getter has been updated to always Do The Right Thing™:
it never returns -1 but, instead, will return the valid drag threshold,
either from the value set or from the Settings singleton.
This change is ABI compatible.
http://bugzilla.clutter-project.org/show_bug.cgi?id=2583
*** This is an API change ***
Replaced the original drag-threshold property with two separate
horizontal (x-drag-threshold) and vertical (y-drag-threshold)
thresholds.
It is some times necessary to have different drag thresholds for the
horizontal and vertical axes. For example, when a draggable actor is
inside a horizontal scrolling area, only vertical movement must begin
dragging. That can be achieved by setting the x-drag-threshold to
G_MAXUINT while y-drag-threshold is something usual, say, 20 pixels.
This is different than drag axis, because after the threshold
has been cleared by the pointer, the draggable actor can be dragged
along both axes (if allowed by the drag-axis property).
http://bugzilla.clutter-project.org/show_bug.cgi?id=2291
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
Both ::drag-begin and ::drag-end have a "button" argument - even though
we assume internally, and externally, that dragging can only be the
result of a primary button operation.
DragAction is an Action sub-class that provides dragging capabilities to
any actor. DragAction has:
• drag-begin, drag-motion and drag-end signals, relaying the event
information like coordinates, button and modifiers to user code;
• drag-threshold property, for delaying the drag start by a given
amount of pixels;
• drag-handle property, to allow using other actors as the drag
handle.
• drag-axis property, to allow constraining the dragging to a specific
axis.
An interactive test demonstrating the various features is also provided.
