Closed floers closed 5 months ago
I might have encountered this bug as well. I had some rough code for adding tooltips in my program. It used @children
inside of a popup window.
When I upgraded to 1.6 this seemed to partially break. However the code wasn't fully functional to begin with, so I just commented it out and went to work on other things without digging too deep.
Thanks both for reporting the issue.
I bisected the change and this is caused by commit 12d904a71ca31f947bfe983e7dbfe745b2439b74
Indeed, the change does change the order between PopupWindow "extraction" and children inlining. So the @children is now in the wrong place.
This could be fixed. However it is still a bit akward to put children in a PopupWindow. It sould be borbidden for the same reason that it should be forbidden to put them in if
or for
as you get the error from bug https://github.com/slint-ui/slint/issues/4438 when trying to access properties of that element.
I feared that you would consider this as "forbidden". I could create a Dropdown like above either with a fixed data model or (if it's sufficient) by just adding a vec of strings for entries (which seems more "the slint way" atm?). But it is very nice to have composability like before. A dropdown is much more generic that way as each consumer can define how options look like. Similar to what TailwindCSS's Headless UI does. For me these patterns are a huge productivity booster.
So if it's out of scope today I can relate but being able to do smth like would elevate slint soo much above other frameworks for me.
Platform: Linux, WASM Language: Slint (Rust)
When using
@children
inside aPopupWindow
the children aren't placed inside the popup window. This worked in 1.5 but doesn't work in 1.6 anymore.Here is a slintpad with an code example: example
And here is just the code example:
The 1.6.0 release notes mention some work on placing
@children
in https://github.com/slint-ui/slint/issues/4935. Maybe this is related.