slint icon indicating copy to clipboard operation
slint copied to clipboard

live-preview: Checks element to decide whether it can be moved

Open hunger opened this issue 1 year ago • 5 comments

Be way more conservative with when an element can be moved around. Look at eleemnt properties, element id, etc.

Start out simple that errs on the side of caution.

This is following up on what Olivier suggested during the coffee break: To disallow dropping onto something, not to forbid drag and drop altogether.

Note that this is very restrictive and basically only keeps really simple objects movable for now. We can lift the limits as we figure out ways to do so.

hunger avatar May 08 '24 16:05 hunger

IMHO this is way too strict. It prevents moving anything in our current example. Like none of the widget of the gallery could be moved because they have bindings.

And yet this is far from sufficient to prevent all errors. (eg, dragging an element that have bindings like row: or col: out of a GridLayout, or moving non-repeated things into a ListView on a non-empty ListView. And that's just some few thing i can think of on top of my head)

So I think this is way too restrictive.

ogoffart avatar May 08 '24 17:05 ogoffart

So it is too restrictive, yet you only list more things I can not allow?

I am getting mixed signals :-)

hunger avatar May 10 '24 07:05 hunger

The latest version allows any move that does not re-parent the element.

hunger avatar May 10 '24 08:05 hunger

So it is too restrictive, yet you only list more things I can not allow? I am getting mixed signals :-)

My point is tat this is too restrictive and prevent the d&d feature to be useful, while at the same time not doing what it's supposed to do: prevent any operation to cause errors.

ogoffart avatar May 10 '24 09:05 ogoffart

My point is tat this is too restrictive and prevent the d&d feature to be useful, while at the same time not doing what it's supposed to do: prevent any operation to cause errors.

Yeap, I know:-/

The only reliable way to detect that moving a element is not going to cause a compile error is to do the change and compile the changed code. Everything else is going to be flawed in some major way.

The compiler is unfortunately too slow to run on every move() event... Do you think we can speed it up for "minor changes" like moving some element somehow? Or maybe have some "check mode" in the compiler that skips most of the passes and the actual code gen? That would be similar to what the LSP does already, maybe I can reuse the logic from there?

It would also require changes to how we do things right now, but the preview has all the code, so we could probably drive the compiler somehow. That could be a step towards not needing an editor to do the actual edits for us, too.

hunger avatar May 10 '24 09:05 hunger

I'll try to compile-test the change now. If that is too slow, we can come back to this and discuss better heuristics.

hunger avatar May 16 '24 14:05 hunger