Commit Graph

41 Commits

Author SHA1 Message Date
Emmanuele Bassi
cd67c7fd24 drag-action: Allow destroying the dragged actor inside ::drag-end
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
2012-09-17 19:54:27 +01:00
Emanuele Aina
59801ef854 drag-action: fix press coords transform with drag_handle
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
2012-08-27 16:21:13 +01:00
Emmanuele Bassi
06ea2cf7b1 drag-action: Ensure that we can destroy the drag handle
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
2012-08-20 19:04:56 +01:00
Giovanni Campagna
f99d48a0c6 ClutterDragAction: allow constraining the movement of the dragged actor
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
2012-08-16 18:21:07 +02:00
Lionel Landwerlin
e2264c0484 Add rotate action
Allow rotation of an actor using 2 points (touch or pointers) events.

Also refactor the accumulators from various actions.

https://bugzilla.gnome.org/show_bug.cgi?id=678587
2012-07-17 16:52:41 +01:00
Emmanuele Bassi
721caece5d drag-action: Add ::drag-progress signal
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
2012-07-11 13:22:19 +01:00
Lionel Landwerlin
132e4b98d1 drag/drop actions: add touch event support
https://bugzilla.gnome.org/show_bug.cgi?id=678049
2012-06-22 21:40:08 +01:00
Emmanuele Bassi
07c95ebf0c Move examples from tests/interactive to a new top-level
The example code that is meant to be XIncluded into the API reference
should not be part of the interactive test suite: it's code that it is
meant to be used as a reference implementation - whereas the interactive
test suite should be allowed to be lean and test behaviour even in nasty
ways. In short: the test suite should not be the place where we show off
idiomatic code for educational purposes.
2012-05-01 19:00:35 +01:00
Emmanuele Bassi
0dd74ca3fb docs: Annotation fixes
The introspection scanner has become slightly more annoying, in the hope
that people start fixing their annotations. As it turns out, it was the
right move.
2012-04-30 17:17:41 +01:00
Emmanuele Bassi
1e3debbd9e drag-action: Use the motion event when passing the drag threshold
This avoids a critical warning, but it also makes the dragging more
fluid in case of threshold crossing.

https://bugzilla.gnome.org/show_bug.cgi?id=670402
2012-02-23 10:51:08 +00:00
Emmanuele Bassi
12a79a66d8 drag-action: Use the symbolic constants for the button
https://bugzilla.gnome.org/show_bug.cgi?id=668692
2012-01-27 09:46:10 +00:00
Emmanuele Bassi
81694d0dd9 drag-action: Use the new event propagation macros 2012-01-12 10:34:50 +00:00
Emmanuele Bassi
8775642e82 docs: Include test-drag as the DragAction example 2011-09-02 14:53:56 +01:00
Emmanuele Bassi
d847d43f70 actions/drag: Be more reliable when destroying the drag handle
Whenever the drag handle gets destroyed mid-drag we need to cancel any
current drag operation and reset the state of the DragAction.

https://bugzilla.gnome.org/show_bug.cgi?id=657681
2011-08-30 13:33:20 +01:00
Peter Ward
2528ad8cb8 Support multiple pointers in ClutterDragAction.
https://bugzilla.gnome.org/show_bug.cgi?id=653066
2011-06-21 18:29:01 +01:00
Emmanuele Bassi
a6a57d7967 drag-action: Remove the drag handle on destruction
When the drag handle actor is destroyed we should unset the field inside
the DragAction, to avoid having stale pointers lying around.

https://bugzilla.gnome.org/show_bug.cgi?id=652842
2011-06-20 14:31:07 +01:00
Emmanuele Bassi
0dea846096 drag-action: Use the dragged actor private API
Use the newly added private API on ClutterStage to track the currently
dragged actor.

https://bugzilla.gnome.org/show_bug.cgi?id=652842
2011-06-20 14:31:07 +01:00
Emmanuele Bassi
b6eb5728e1 stage: Make per-actor motion event delivery accessors public
Complete the quest of commit bc548dc862
by making the ClutterStage methods for controlling the per-actor motion
and crossing event delivery public, and deprecating the global ones.
2011-06-20 11:41:28 +01:00
Emmanuele Bassi
a76e0041af drag-action: Fix a compiler warning
Use arguments of the right signedness when passing pointers.
2011-03-21 12:41:40 +00:00
Emmanuele Bassi
82a30d8e0b drag-action: Allow using settings for the drag threshold
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
2011-03-09 14:21:01 +00:00
Jasper St. Pierre
0c576c0c33 Remove private helper #define's
Finish off the second half of 09a830d294.

http://bugzilla.clutter-project.org/show_bug.cgi?id=2596
2011-03-03 11:47:49 +00:00
Emmanuele Bassi
a923375f0a drag-action: Use per-stage motion event toggle
Similar to what we did for the ClutterDeviceManager, use per-stage
granularity when toggling the motion event delivery while dragging.
2011-02-18 19:41:57 +00:00
Lucas Rocha
c61e22d067 drag-action: fix case where motion events are indefinitely disabled
When drag threshold is not reached, emit_drag_begin() is not called
causing default value of priv->motion_events_enabled (false) to used to
restore motion events enabled state in Clutter. This causes drag action
to indefinitely disable motion events. The current value of motion
events enabled state is now queried on button press which guarantees
that the state will be restored with the correct value in
emit_drag_end()

http://bugzilla.clutter-project.org/show_bug.cgi?id=2522
2011-01-18 14:48:14 +00:00
Emmanuele Bassi
63cef64d17 docs: Fix some wrong function/signal/property names 2010-11-18 15:21:16 +00:00
Emmanuele Bassi
09a830d294 Remove conditional wrappers for property installation/notification
For the time being, just keep the #define's.
2010-10-18 11:26:45 +01:00
Emmanuele Bassi
f753b0c4a1 Wrap g_object_class_install_properties()
GObject ≥ 2.26.0 added a nice convenience call for installing properties
from an array of GParamSpec. Since we're already storing all GParamSpec
in an array in order to use them with g_object_notify_by_pspec(), this
turns out nicely for us.

Since we do not depend on GLib 2.26 (yet), we need to provide a simple
private wrapper that implements the fall back to the default
g_object_class_install_property() call.

ClutterDragAction has been converted as a proof of concept.
2010-09-30 10:33:24 +01:00
Emmanuele Bassi
7d2706e8ba docs: Fix the name of the parameters 2010-09-15 16:12:56 +01:00
Henrik Hedberg
1eae9fcd7e drag-action: Added x-drag-threshold and y-drag-threshold properties
*** 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>
2010-09-07 10:40:49 +01:00
Emmanuele Bassi
ad0c36e1a1 docs: Fixes to avoid gtk-doc warnings 2010-08-17 14:54:20 +01:00
Emmanuele Bassi
9b736cfeba drag-action: Capture ENTER when dragging
This completes commit 9ab83cebf.
2010-08-12 08:53:06 +01:00
Emmanuele Bassi
9ab83cebfd drag-action: Capture stage leave
If we are dragging, we don't want the drag handle to emit a
::leave-event even if the pointer left the stage.
2010-08-11 14:42:56 +01:00
Neil Roberts
8d51617979 Conditionally use g_object_notify_by_pspec
This adds a wrapper macro to clutter-private that will use
g_object_notify_by_pspec if it's compiled against a version of GLib
that is sufficiently new. Otherwise it will notify by the property
name as before by extracting the name from the pspec. The objects can
then store a static array of GParamSpecs and notify using those as
suggested in the documentation for g_object_notify_by_pspec.

Note that the name of the variable used for storing the array of
GParamSpecs is obj_props instead of properties as used in the
documentation because some places in Clutter uses 'properties' as the
name of a local variable.

Mose of the classes in Clutter have been converted using the script in
the bug report. Some classes have not been modified even though the
script picked them up as described here:

json-generator:

 We probably don't want to modify the internal copy of JSON

behaviour-depth:
rectangle:
score:
stage-manager:

 These aren't using the separate GParamSpec* variable style.

blur-effect:
win32/device-manager:

 Don't actually define any properties even though it has the enum.

box-layout:
flow-layout:

  Have some per-child properties that don't work automatically with
  the script.

clutter-model:

  The script gets confused with ClutterModelIter

stage:

  Script gets confused because PROP_USER_RESIZE doesn't match
  "user-resizable"

test-layout:

  Don't really want to modify the tests

http://bugzilla.clutter-project.org/show_bug.cgi?id=2150
2010-08-10 17:12:06 +01:00
Emmanuele Bassi
fd27ca7398 Mark property strings for translation
Both the nick and the blurb fields should be translatable, for UI
builders and other introspection-based tools.
2010-07-15 14:07:07 +01:00
Emmanuele Bassi
62c08b4a09 drag-action: Disable picking during drag
While dragging we don't need to perform picking to determine the actor
underneath the pointer, for two reasons:

  • we use a capture on the stage to determine the motion delta.
  • we know the actor underneath the pointer because that's the
    actor we are dragging around.

This change should make dragging actors in complex scenes a bit faster.
2010-06-22 16:12:53 +01:00
Emmanuele Bassi
f97d16cd2d drag-action: Remove the press event button
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.
2010-06-12 17:45:54 +01:00
Emmanuele Bassi
b2c905ff50 Hide the marshallers
The marshallers we use for the signals are declared in a private header,
and it stands to reason that they should also be hidden in the shared
object by using the common '_' prefix. We are also using some direct
g_cclosure_marshal_* symbol from GLib, instead of consistently use the
clutter_marshal_* symbol.
2010-06-11 16:09:36 +01:00
Emmanuele Bassi
b77c0c91d7 drag-action: Re-use press_button in emit_drag_end()
Since emit_drag_end() can be called from a MOTION event capture we
cannot call clutter_event_get_button(). We should, instead, use the
press_button value because if we're emitting ::drag-end it means we
also emitted ::drag-begin and the value is valid.
2010-05-27 12:30:22 +01:00
Emmanuele Bassi
cfb05bfb09 docs: Fix DragAction documentation
The ::drag-motion signal does not have a ModifierType argument; also,
there's no need to connect to the ::drag-motion signal any more.
2010-05-25 13:11:51 +01:00
Emmanuele Bassi
728e2d8071 drag: Add a default drag-motion behaviour
The DragAction should, by default, drag the actor to which it has been
applied, instead of delegating what to do to the developer. If custom
code need to override it, g_signal_stop_emission_by_name() can be called
to stop the default handler to ever running.
2010-05-25 11:01:46 +01:00
Emmanuele Bassi
6457f66976 Miscellaneous documentation fixes 2010-05-19 16:10:05 +01:00
Emmanuele Bassi
4fd74e71e6 action: Add DragAction, an action implementing drag capabilities
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.
2010-05-17 16:42:11 +01:00