> But that's exactly my point. TablePane has an implicit "fill" behavior in > each of its cells. True, it figures out the size of a "-1" row or column by > taking the maximum of the preferred sizes of its elements. But once it's > determined the row/column size, either that way or by using the TablePane > size declarations, it forces *everything* in the row/column to "fill" the > orthogonal dimension, totally ignoring any preferred sizes given. Hence, my > question, "Would it make sense for an explicit preferred width/height on a > component to trump fill?"
Ah, OK. I understand the question now. But I don't think that an explicitly set preferred size should be treated any differently than a default size. That establishes a precedent for inconsistency and might create more problems than it solves. I think it would be preferable to simply add support for alignment to table cells. > since you think of alignment as a style property, I can't even propose having > an attached property to handle that. That's a good point - though I think in this case an attached property might be OK. > A vertical BoxPane with fill=true is perhaps a more compelling usage case. > It would be nice if I could have such a pane fill, so that my paragraphs of > text could wrap, but still be able to not have other components stretched to > the full width of the pane, as I was trying to achieve in my original example > but was forced to wrap in a BoxPane to kill the fill. I understand the motivation. But it still comes back to the same question - how do you know which components should wrap (i.e. be "filled") and which shouldn't? You'd need some way to specify that. You might be able to use attached properties to control alignment on a per-component basis. But that would be a pain when you know you want all components to use the same alignment (probably the more common case, at least for box panes). The current solution allows you to manage alignment of each component by nesting box panes, but you can still manage the overall alignment with a single style. I'm not trying to suggest that the current implementation can't be improved - just that there are some design challenges to be considered when thinking about how to improve it. G
