I’ve been trying to fix some issues with WebPositivew, WebPositive has some buttons that at default 12px font size want a size of 18x12, so they wish to be a bit wider than high. For example the new tab button fits this.
Now, at font sizes higher than 12 this quickly falls apart, their width is respected, but their height just uses the height of the tab bar. Using HeightForWidth works… by making the buttons smaller; so they are now the original size, not scaled, and way too small.
What would the correct way be to make the buttons keep their aspect ratio, i.e setting their width based on their height? Do we need a WidthForHeight call?
I’m tempted to use a hack to get the preffered height of the tab bar directly somehow instead, and set the initial preffered size based on that, but that feels icky as a solution.
HeightForWidth is designed for much complex cases (for example when there is word wrapping involved in a text view). Your case seems pretty static and only depends on the font metrics / UI scale.
So, just set fixed constraints depending on that.
The layout is usually computed from the bottom (the size constraint of each individual item) to the top (the overall window). There isn’t much room for going back and forth (sizing the top view, then adjusting the inner controls again, and so on) because that may not converge.
Maybe you can use the Aukland Layout Model (BALMLayout) if you really want to do something like that. Then you can have linear constraints as you are trying to express (“this button has a 3:2 aspect ratio”) and let the layout model resolve them. But with the other layouts, this is pushing the limits of what you can do.
1 Like
Something based on StringWidth then? I will try that.
I had started using HeightForWidth for one Control In WebPositive, the close button of the cmd+f searchbar, because without it the button became wide and not square.