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.
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
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.