> 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.
But this is the question I have been asking Noel - without the fill style, how would it know where/when to wrap? > 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.) Yeah, that part of the design was inspired by CSS. > > 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. Yeah, that's possible. But I'm not sure how it might be done without making BoxPane less useful or introducing some redundant layout behavior. > > 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? It doesn't. TablePane also tries to respect the preferred size of its cells. But when a TablePane isn't given its preferred size, it can't give its children their preferred sizes, either. So it resizes the cells based on the cell width and row height 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? :-) > > 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?) I'd suggest creating a JIRA ticket for it, then do: diff > pivot_xxx.patch from the root of the source tree.
