Currently, it seems that a window determines its size based on the value passed to it by the user and then forces its contents to be laid out within that size.
However, it's often more useful and convenient to do it the other way around: The window should use the usual box layout methods on its content to determine the best size for itself within the usual constraints (which should be user-settable on the window).
Whether to do this, of course, should be an option settable on the window.
Furthermore, there should be separate options to control whether this size can grow and/or shrink in response to future layouts.
This way, it's possible to have a completely dynamically sized window, where showing/hiding UI (for example) inside the window will automatically grow/shrink the window as well.
(I know druid is WIP, but I like it and I didn't see a way to do this nor an existing issue on it, so I've though to open one)
This would be nice to have indeed, but I don't think our current (rather primitive) layout system could do this.
Would be interesting to know how Flutter deals with this.
How should we solve this for widgets that do not have a fixed size, for example the ones that take up any free space left. Should they be considered as having some default width and height (for calculating the window size)?
I think this isn't practical, for both theoretical and technical reasons.
Theoretical: for box constraints to work, you need to have some base constraints; if your initial constraints are (0, 0) and (inf, inf) it will be hard to actually produce a valid layout.
Practical: window managers impose constraints on the size windows can be. On some devices (mobile, e.g.) windows have a fixed size. In addition, when a window is restored on launch from a previous size, we would like to respect that, and use the existing size when computing the initial layout.
I definitely agree, I don't think it's reasonable to ask window size to react nicely as a root node in the layout system used for widgets. But it would be nice to be able to push-pull on this a bit more. Could we grow the ability to set the window size through a Ctx, and the ability to change min/max sizes?
I'm not familiar with the platform restrictions around this to know how feasible it might be.
yes, we could totally expose access to various window properties through contexts or commands. Some of this may already exist as part of #1235.
Most helpful comment
I think this isn't practical, for both theoretical and technical reasons.
Theoretical: for box constraints to work, you need to have some base constraints; if your initial constraints are
(0, 0)and(inf, inf)it will be hard to actually produce a valid layout.Practical: window managers impose constraints on the size windows can be. On some devices (mobile, e.g.) windows have a fixed size. In addition, when a window is restored on launch from a previous size, we would like to respect that, and use the existing size when computing the initial layout.