> > Also, what you are describing is *not* consistent with Label and ImageView. > The alignment styles of those components control the alignment of their own > content, not how they are positioned within a parent container (exactly the > way the corresponding styles in BoxPane behave). >
Wow, there's a lot of confusion in this thread, including my own -- I didn't realize that horizontalAlignment on a BoxPane or Label referred to the positioning of its contents. I had been working off a faulty analogy with WPF there, so my request for a horizontalAlignment for everyone (in ComponentSkin), which controlled placement within a parent, would be more of a change than I realized. In light of that, I agree with Greg that it wouldn't make sense to change anything about Border. Noel talks about the double duty of BoxPane's fill property. 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. But it's too late for that now -- such a change would break existing layouts. (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. Were we designing Pivot from scratch, I'd propose no fill property on any container (but instead passing to all their children their size constraints in whatever way makes sense for the container, such as BoxPane in the orthogonal dimension), and create a different container, say "Aligner", for role (2). However, at this point, I'm not sure what would make the current situation less confusing, except possibly one thing, which I'll rephrase from one of my earlier questions. 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? Given that, then what do preferred width/height really mean, and why should a parent's fill behavior cause those properties to be ignored? 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. 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.
