Created attachment 140209 [details] [review]
workspaces: Create drag actor for clone rather than using actor itself

*** Bug 591157 has been marked as a duplicate of this bug. ***

Replying to a comment from bug 588474
(In reply to comment #24)
> (In reply to comment #16)
> 
> > (mutter:15604): Clutter-WARNING **: Actor of type ClutterClone is not inside a
> > container
> 
> I think this is because when we accept a drop, dnd.js does:
> 
>                     // If it accepted the drop without taking the actor,
>                     // destroy it.
>                     if (actor.get_parent() == actor.get_stage())
>                         actor.destroy();
> 
> How exactly this should all work if you haven't created a specific drag clone
> I'm not sure, but I think it's better to create one anyways so that we can make
> it partially transparent, which lets you actually see where you're dropping it.
>  We should probably scale it down too.  That's in bug 591158.

Hmm, I guess when dragging to the window well, it's awkward to drop a big full window, but I think direct manipulation is more comfortable for moving things between workspaces and feels more natural. And that's the primary use case for dragging windows. If you wanted to created a launcher for the app, you are likely going to drag the icon from running apps, which is a lot closer and more "appy"

Look at how acceptDrop works for Workspace - that looks like it will break badly with this patch.

I think the right fix is do:

   if (actor.get_parent() == actor.get_stage()) {
       this._releaseDragActor();
   }

Where _releaseDragActor is the stuff at the beginning of _onSnapBackComplete() refactored out.

Created attachment 140222 [details] [review]
dnd: If drop accepted without taking actor, do snapback

The workspaces uses DnD in the mode where the dragged item is its
own drag representation.  Fix the case where a target accepts the
drop but does not take the actor by doing a snapback.

Created attachment 140223 [details] [review]
workspaces: Make actor partially transparent on drag

Useful to see where you're actually placing it, especially with
larger windows.

(In reply to comment #4)
> Created an attachment (id=140222) [edit]
> dnd: If drop accepted without taking actor, do snapback
> 
> The workspaces uses DnD in the mode where the dragged item is its
> own drag representation.  Fix the case where a target accepts the
> drop but does not take the actor by doing a snapback.

I don't think this is right - snapback is an indication that the drag failed.

(In reply to comment #6)
> (In reply to comment #4)
> > Created an attachment (id=140222) [edit]
> > dnd: If drop accepted without taking actor, do snapback
> > 
> > The workspaces uses DnD in the mode where the dragged item is its
> > own drag representation.  Fix the case where a target accepts the
> > drop but does not take the actor by doing a snapback.
> 
> I don't think this is right - snapback is an indication that the drag failed.

Fair enough...hm.  Maybe we add a way for the application well to tell DnD "I accepted the drop, here's the actor which represents the target".  So we could animate the window shrinking down into its launcher, or some effect like that.  Or other ideas welcome.

For now I think it's fine if the window just reappears in its old position after release, but without the animated snapback.

Comment on attachment 140223 [details] [review]
workspaces: Make actor partially transparent on drag

(In reply to comment #5)
> Created an attachment (id=140223) [details]
> workspaces: Make actor partially transparent on drag
> 
> Useful to see where you're actually placing it, especially with
> larger windows.

Trying this out in isolation it doesn't feel like much of an improvement to me. There's a bit of a "ooh shiny transparent" buzz, but it makes dragging windows between workspaces feel less solid and less like direct manipulation.

My best take on the right behavior:

 A) When you start dragging, you "pick up" the window and its fully opaque
 B) If you leave the workspace area (the bounds of the currently present workspaces plus maybe a few pixels slop), then the drag icon abruptly changes from the window to the app icon and the window fades back in at its original location to indicate that you aren't going to move the window.
 C) If you go back to the workspaces the drag icon change reverses and you go back to dragging the window (with the original "pick up" location)
 D) A failed drop snaps the icon back to the location of the window.

Optional bonus points:

 The window fades back out from the original workspace location when you are over the add-workspace (+)

(In reply to comment #9)

> Trying this out in isolation it doesn't feel like much of an improvement to me.
> There's a bit of a "ooh shiny transparent" buzz, but it makes dragging windows
> between workspaces feel less solid and less like direct manipulation.

Forgot to add the other half of what I was going to say here:

And when you are dragging to the app well, you still feel like you are trying to cram a gigantic object into a little box - the fact that the point location is the hot spot isn't intuitive even when you know that is in fact in case.

Close obsolete? Much of this has been reworked/tried while landing the window dragging in linear view stuff ...

i think owen's last comment about "cramming a gigantic object into a little box" is still relevant (other than the part where that's currently broken, but...)

Old bug with no activity for over three years. Are we sure that we still need it?

I don't think so - dragging windows to the dash as mentioned in comments #10 and #12 was removed quite a while ago by now ...