For some use cases we have other behavior on mouse press and want
to manually control when a drag starts. Split out the drag initiation
code into startDrag.
We had multiple copies of the code to position a drag actor given a particular
source. Instead, just put it inside dnd.js.
Second, rather than test for GenericDisplay/WellDisplayItem etc.,
in various places, add a new method on each source "shellWorkspaceLaunch"
which both marks the item as being droppable on a workspace, and is
called by the workspaces code to launch the item.
The variables this._yOffset and this._xOffset are included in the
drop coordinates, but as far as I can tell never defined. Looking
back on the commit that introduced this code, they weren't removed
from anywhere else either.
The drop coordinates seem correct without them, so just delete them.
Emit the signal at the correct time to take action
on snapback (i.e. after the end of the snapback animation).
Add a boolean to the drag-end signal saying whether it was accepted,
which ensures consumers know whether the drag was successful.
- clutter_actor_get_transformed_position()/size() return floats
- clutter_stage_get_actor_at_pos() takes a pick mode
- ClutterTimeline no longer has a concept of frames
- ClutterUnit is now replaced by float
- cogl_texture_new_from_data() signature changed
http://bugzilla.gnome.org/show_bug.cgi?id=585013
Sliding the workspaces back in when the user starts dragging an item in the
expanded display mode allows the user to select a workspace in which the item
should be launched and stay in the overlay mode.
This patch adds code to dnd.js that handles notifying actors when a drag item is being dragged over them. Overlay code uses such notification to unset expanded display modes and trigger sliding in of the workspaces.
If the drag is cancelled the drag item snaps back to its source or disappears at the original position of its source if the source is no longer displayed.
