Relative size changes for Toolkit layouts


Our current trunk version is rather dummy when it comes to relative sizes in layouts. (OrderedLayout especially) If layout has defined size (either horizontally or vertically), that size is split for all components. Then 100% for child component is parentSize/numberOfChildren. Good for implementing chessboard, but…

So we had some long negotiations in Rn’D and finally came up with a new specification draft. Actually we are so sure that it is much better than the last one that there is already some prototyping going on. It will cause some small changes to some applications, but I believe that most of Toolkit users will finally be rather happy with the new system.

So if you want to share our idea, now is the time. Check the RFC doc from wiki and share your thoughts here on the forum.


I try to summarize the idea briefly:

  • A layout, with no size specified, consumes as much space as its child components require
  • %-sizes for the components are relative to the space left over from the (explicitly or implicitly) pixel-sized components in the layout
  • Any space left, after the space for (explicitly or implicitly) pixel-sized components and %-sized components is reserved, is equally divided between all components

By pixel-sized you most likely mean
any other unit than percentages
, am I right?

Yes. “Implicitly pixel-sized” above includes:

  • Components with no size specified. They take as much space as they naturally would like to take.
  • Components sized with any other unit than % where the pixel size can be calculated by setting the “1.5em” and then getting offsetWidth/offsetHeight


If some of you have been following this tread and what is happening in trunk, you must be wondering what the f#%k is going on. What is going on is that we changed the plan once again.

I updated the wiki page to reflect the current idea.

As always, comments and ideas are welcome!