When the app sets the width/height of a control and places it in a container, which promptly resizes it to its preferred size. Turns out this is by-design and the supported way of handling this is to override the control’s preferred size like this:

layoutInfo: LayoutInfo { width: myWidth height: myHeight }

However, this is not necessarily intuitive and I have a number of JIRA issues filed because developers were surprised that their width/height settings were lost when the control was placed in a container (e.g. hbox/vbox). I haven’t closed the issues as “will not fix” until time convinces me developers just need to learn this idiom.

This could also be interpreted as having the size self-managed by the control if it is set to false.

Some other reasons why this conveniently works out include:
* It defaults to true (which is exactly what you wanted for your autoSize proposal)
* It resizes the component properly in the non-managed Container case
* It works with other UI elements that are not Controls (e.g. Charts)

I fully agree with Simon, unless you need special effects, most controls should have a fixed size, and in case of special effects, if the control extends Resizable (they all do, no?), you can just change width or height properties.

When you change the content of a control, you can also trigger a resize request, eg. fitTocontent() or similar. Or provide functions to get the size of the modified content, depending on font and stuff, so that the program can resize manually the control (might want to stick to a number of predefined sizes, add margins, etc.).

Just throwing some ideas…

Perhaps a better strategy might be to not have the controls dynamically resize simply because their contents have changed (obviously fonts changes, etc, are a different matter entirely), but to provide easier ways to hint at their maximum potential size, without having to monkey about with pixel dimensions…

Button {
text: “Ok”
maxText: “Cancel”
}