> I think the real double duty is BoxPane itself. > (1) It is a simple way to place a series of components linearly in a > container. In that role, it really would be more logical for it to behave as > if it had fill=true, much like many other containers implicitly do.
While it is common to use BoxPane with fill=true, it is also pretty common to use it with fill=false and some alignment values. So I think having support for both is handy. > (2) With its default fill=false, it is a kind of wrapper (maybe the only one > in Pivot?) that allows you to position a single component within a "filled" > container, much as I do in the example that started this thread. FlowPane also allows you to do this. The main difference is that FlowPane will wrap, whereas BoxPane does not. FlowPane also doesn't support a fill style. An "AlignmentPane" might help, but it would be kind of redundant, since it would basically be a box pane that is limited to one child component. I do wonder if maybe providing alignment support for table cells might not be a bad idea. > Were we designing Pivot from scratch, I'd propose no fill property on any > container The problem is that, without some concept of "fill" (or "justify"), there's no way to determine width or height constraints, so wrapping wouldn't work. > Would it make sense for an explicit preferred width/height on a component to > trump fill? Today, if I want my component to fill the space available in its > parent, I simply don't specify a size, right? It depends on the container you put the component in. StackPane and Border, for example, will always size their children to fill. BoxPane with fill=false will not, nor will FlowPane. TablePane will size each cell component to fill (to the column width/row height of the cell). > Given that, then what do preferred width/height really mean, and why should a > parent's fill behavior cause those properties to be ignored? They are hints to the container. They also help the container determine its own preferred size. For example, a Border will report a preferred size equal to its content's preferred size plus the border thickness, padding, etc. If a Border is placed in a container that respects preferred size, then its content will also be given its preferred size. In all cases, though, Border simply sizes its content to fill its available client area. > I second Roger's point that we could use a tutorial on how layout works, and > how to think about it. A less elaborate way to help in this regard might be > to document (in the javadoc) many more of the current style properties. For > example, at the moment, there is no doc at all for BoxPane#setFill and > BoxPane#setHorizontalAlignment. Given all the confusion in this thread about > those properties, a little javadoc might head off the next round of same. Agreed. Any volunteers? :-) > I notice that Pivot has a barely populated Wiki. Can anyone contribute to > it? I've been thinking recently that I ought to write up some kind of "Pivot > for the WPF programmer" advice. It's not public, but if you have an account on the Wiki you can be granted access.
