> > > (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. >
Hmm, true, given what I have now come to understand about alignment. On the other hand, I think alignment should to some extent trump fill, though not completely. E.g., you ought to be able to have alignment=center, which would mean all components are centered and not stretched to the full width, but the width of the BoxPane still should be a size constraint on its children, so that, for example, text could wrap. In the absence of a fill property, this would imply an additional default alignment value, call it "stretch" or maybe even "fill". > 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. > Would it make any sense for there to be an attached property of that sort? E.g., in my original example, I'd have said BoxPane.horizontalAlignment="center" for the 1st and 3rd components. Oh, wait, alignment is a style property. (Another source of confusion for me, really. I get how font and color and such are styles and might change if you had a global style (skin?) system, but alignment? Well, maybe so. CSS has it, after all.) > 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. > I didn't mean to suggest that there wouldn't be fill behavior, just that it wouldn't be exposed. Lots of containers today implicitly fill, while only a few (notably BoxPane) have an explicit property to control it, something which has clearly led to a lot of confusion. If all containers filled automatically where it made sense, you'd get fewer of those "why isn't my text wrapping?" questions. > > 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. > So you've just demonstrated the recursive aspect of my question. If I set a preferred size on a component, and stick that component inside a Border, the latter now also has a notion of preferred size. If the Border is then placed inside a TablePane cell, why should the TablePane cause it to ignore that size? 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? :-) > If you're suggesting that I'm one, okay, what is the protocol? My suggestion involved editing a whole bunch of source code. Do I do that and submit patch files or something? (And if so, is there anything in Eclipse to make that easy?)
