cmd+dragging a view / element / component causes unpredictable behaviours based on parent layout mode about utopia

[maltenuhn]

I'll fill in some more things from the discussion with @balazsbajorics here, and then separately comment on @Rheeseyb your (super helpful) notes.

The core issue is precisely that dragging gives you two things that are mutually incompatible:

1. I feel like I'm control of this thing. It doesn't suddenly stop moving (because it's in a flex context) or "go away" (because I'm dragging over a component that supports props.children but doesn't render them by default)

2. I know what would happen when I let go. If drop this here, it won't end up exactly here, but somewhere else (because it's a flex context, or a flow context). If I drop this there, it won't show up at all (because the component swallows its children). And if I drop this over there, it will transform weirdly.

(1) is direct manipulation, (2) is instant feedback. For design tools, they often go hand in hand, because very few situations will manipulate, transform, hide, or swallow things you're dragging. For us, they diverge - especially with components and styles-that-apply-to-children (transforms, opacity).

However, the solution is on one level quite straightforward, and pretty much what we did previously: show a placeholder and extra controls for (2), show the real element for (1), and after letting go use an animation to make the two converge. -- In theory we could do it the other way 'round (a placeholder that follows the mouse, the real thing moving in and out of containers. We previously didn't do this because (IIRC) of perf concerns.

And: it doesn't need to be perfect. In particular, one of the two does not need to be real or realistic, or even fast - as long as the other is. E.g. Previously we made the placeholder a pink rectangle - almost a "shadow" of the real element - and that worked well because the real element tracked the mouse with very high speed (fueled by our tears of rage, I'm sure you remember / have suppressed this :).

[balazsbajorics]

(I'm on the phone with Malte)

Spike 1 for a possible solution would be to make sure that we can make a "screenshot" of the dragged element, and only the dragged element (do not include things that are visually below it or over it etc).

[Rheeseyb]

I was just having a look at this to see how simple that proposal would be, and I think this is a bigger problem than that proposal would solve.

So the underlying issue here is that sometimes we don't want the rendered controls to map 1-to-1 with the outcome, and sometimes in those cases we also want the rendered controls to include a version of the thing being updated. So some example cases:

• Dragging an element that is in a flex container (no change of parent) - the controls should stick to the mouse, but we should show the result of the drag too. In this case having a placeholder rendered in the final location worked nicely. Having a snapshot of the element as part of those controls (and also applying the result in real time to the actual element) means you'll see the element twice, with overlapping occurring in a lot of cases. If we adjusted the opacity that might help, but then what if the thing being dragged already has partial opacity?
• Dragging an element to re-parent it into a container that changes the layout - very similar situation to the above, but if the re-parent were to trigger the element to disappear completely then having the semi-transparent snapshot in the controls would certainly make it clearer what is happening here
• Dragging to move (or even resize) an element that has some transforms applied to it - as much as it will be painful to create the controls for this (though we did find a library that would help before), you'd probably want the controls to reflect that transform (something that is being partially wrestled with in #91 ). In this case it feels like you wouldn't want to see the placeholder result or the snapshot in the controls?

IMO what we had in legacy partially solved the first two (I'd say we should also adjust the opacity of the dragged thing if the result doesn't match the controls 1-to-1), but not the second. Is this worth further discussion before someone undertakes that spike?

[Rheeseyb]

I have a branch with this partially solved (feature/drag-controls-stick-to-cursor), but this requires further experimentation, so I'm going to move this to Triage so we can address this together with other experiments we want to run around canvas controls

[Rheeseyb]

Change of plan. I have opened a PR to cover the work from that branch. We will re-address the remaining issues as part of an upcoming process of experimenting with various canvas controls.