Closed bjorn closed 10 months ago
In order to understand this, we must understand that the preview UI uses itself Slint and uses this UI:
i-preview-area-container := ComponentContainer {
width: max(self.min-width, min(self.max-width, drawing-rect.width));
height: max(self.min-height, min(self.max-height, drawing-rect.height));
}
The ComponentContainer will get the inner's window property and create this binding:
width: i-preview-area-container.width;
height: i-preview-area-container.height;
It comes naturally that we then have this binding loop:
ComponentContainer::layout_info -> root_window-1.layoutinfo-h -> root_window-1.root-2-layoutinfo-h -> root_window-1.empty-3-layoutinfo-h -> root_window-1.empty-3-padding-left -> root_window-1.width -> i-preview-area-container.width -> i-preview-area-container.max-width -> ComponentContainer::layout_info -> load_property_helper root_window-1.layoutinfo-h !!!!
We'll have to break that loop somehow.
Note that in principle, this kind of loop already exist and should probably be forbidden by the compiler as they tend to cause issues like https://github.com/slint-ui/slint/issues/2902 This works because when not using a ComponentContainer, the normal window break the layout by letting one event loop iteration in between the min-max size query and width/height adjustement. But if the loop is actually real and doesn't converge, it creates infinite changing size.
Platform: Linux, Language: Rust, Editor: VS Code
The following component is crashing the LSP when I press "Show Preview":
It appears to be triggered by the
padding-left: parent.width * 0.015;
line, since the crash disappears when the line is removed.The backtrace: