slint
slint copied to clipboard
live-preview: Checks element to decide whether it can be moved
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.
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.
So it is too restrictive, yet you only list more things I can not allow?
I am getting mixed signals :-)
The latest version allows any move that does not re-parent the element.
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.
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.
I'll try to compile-test the change now. If that is too slow, we can come back to this and discuss better heuristics.