If the drag actor is destroyed as part of a drag target accepting it,
we were not calling ungrabEvents, meaning the mouse/keyboard remained
grabbed until you clicked somewhere to cancel it.
This fixes that without trying to improve the extremely confusing
control flow...
https://bugzilla.gnome.org/show_bug.cgi?id=635278
Previously, when snapping back a drag actor, we moved it back to its
original stage-relative position and scale. This worked fine if its
parent was still in the same place it was when the drag started, but
failed in cases like the linear workspace layout window drag-and-drop,
where dragging a window would "zoom out" its parent workspace, causing
the snapback to send it to the wrong place.
Fix this by instead snapping the actor back to "where the actor would
have been right now if it were still at its original scale and
position within its original parent actor" rather than "where it was
before the drag started"
https://bugzilla.gnome.org/show_bug.cgi?id=635272
Instead of hiding the drag actor temporarily to determine the actor
beneath it, make it invisible to picks while dragging using the new
shell_util_set_hidden_from_pick().
https://bugzilla.gnome.org/show_bug.cgi?id=634560
Return a DND.DragMotionResult constant from delegate _handleDragMotion
methods as well as the existing return value from the drag monitor method dragMotion.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
Sometimes it is desirable to be able to react to DND events that
happen outside a target actor's bounds, e.g. to implement reactive
screen edges. Add a simple interface which allows to hook into
drag motion and drop handling without jumping through ugly hoops.
https://bugzilla.gnome.org/show_bug.cgi?id=620504
While zoomed out, the workspaces view's drop target spans the entire
monitor to implement reactive screen edges. When a drop event is not
handled by the view, an attempt is made to pass it on down the stack,
but it doesn't work properly. Fix it by iterating the target's parents
as well.
Also improve the code which translates dnd coordinates to target
positions.
https://bugzilla.gnome.org/show_bug.cgi?id=619203
Currently, the drag and drop code assumes that on a successful drop
the target will either consume the drag actor or that it is otherwise
OK to destroy the actor.
As the drag behavior for window preview was changed, dropping a preview
on the dash now results in the preview being swallowed - to fix, add an
option to restore the actor in case of a successful drop as well.
https://bugzilla.gnome.org/show_bug.cgi?id=619203
This is our convention.
The only exceptions are double quotes for words in comments that give
them a special meaning (though beware that these quotes are not truly
necessary most of the time) and double quotes that need to be a part
of the output string.
In preparation for adding magnification, "uiGroup.patch", organizes the stage
along the following lines:
Stage
*Magnifier
UI group
Window group
Chrome group
Overlay group
Alt tab
App display
Chrome
...
This allows a magnifier actor to clone and magnify the UI group. The magnifier
is a sibling of the UI Group in this stage oraganization -- see the next patch,
"Magnifier.patch".
Currently manual dnd mode is used with St.Clickable to avoid messing
up its internal state with a pointer grab. To avoid code duplication,
move this special handling into dnd.
https://bugzilla.gnome.org/show_bug.cgi?id=610385
These variables were computed strangely; through cancellation
they'd end up being negative 1/2 the width/height of the actor,
so just use that directly.
https://bugzilla.gnome.org/show_bug.cgi?id=607821
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.
