It should be possible for a window to get its size from its contents

[insignification]

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)

[luleyleo]

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.

[rhzk]

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)?

[cmyr]

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.

[Zarenor]

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.

[cmyr]

yes, we could totally expose access to various window properties through contexts or commands. Some of this may already exist as part of #1235.

[rjwittams]

WindowSizePolicy::Content does this and resizes on every layout. It was made for the popups/dropdowns in the nursery.
I think it fulfills most of this but doesn't currently interact well with resizing.

[jeberger]

I have the feeling that the current layout process is working in the wrong direction: it doesn't really make sense for a container to impose a minimum size on its children, and conversely there is no way for a child to convey its minimum size requirement to its parent. Here's a suggestion for a layout system that would allow window sizes to adjust to their contents:

• Widgets have a method that returns their constraints. Constraints include at least a minimum size, and possibly a maximum and preferred size.
• During the layout phase, constraints propagate bottom-up: containers ask their children for their constraints, add their own requirements and return the aggregated constraints.
• During the paint phase, layout is applied top-down: containers are given a size by their parent, choose their children sizes taking into account their constraints and pass the chosen size to each child.
• In answer to Clarification of behaviour and expectations of the layout API #1242, the paint box that is given to each widget should always respect the constraints that the widget expressed during the layout phase. However specialized containers may propagate relaxed constraints from what their children requested during layout and take appropriate actions to adjust the size when painting (eg. add scroll bars, add padding, crop or scale).

This way, top-level windows can know the minimum size of their children and adjust automatically to them.