Greg Brown wrote: >>>> At the moment, the "fill" style of BoxPane is doing double duty. >>>> It means two things for a vertical boxpane >>>> (1) make the component fill the available width if the component is >>>> smaller than the boxpane width >>>> (2) if the components preferred width is greater than the available width, >>>> cut off the component. >>> Actually, in #2 the component isn't simply clipped to the box pane's width >>> - it is given its constrained preferred height. This gives the component a >>> chance to wrap its content, which wouldn't be possible without the fill >>> style (we need a width to constrain against). >>> >> Yeah, but we want to give components the chance to wrap even if fill is >> false, which is not currently the case. > In order to wrap, a component needs a width constraint. The "fill" flag > allows us to use the width of the BoxPane as this constraint. Otherwise, how > would we know what the wrap width should be? The only other way to do it > would be to assign an explicit preferred width to the component. > In layout(), we have a width constraint we could use, which is the width that has been allocated to us. Similarly in getPreferredHeight(int). I already prototyped this, so I know it solves Bill's problem. (but I haven't implemented a complete solution yet).
>>>> Border could do with having alignment and fill styles, which is a fairly >>>> straightforward change and would make this >>>> class more useful. >>> It could, but I'm not sure how much value that might really offer. How >>> often do you want to put something in a border that doesn't completely fill >>> the internal space of the border? Probably not that often, and when you do, >>> you can use BoxPane, TablePane, ScrollPane, etc. >>> >> Alignment and fill would affect how the bordered component sits within the >> space allocated by the parent container. So >> if I wrap a component in a border and put it inside something else, I don't >> necessarily want it to fill the space within >> it's parent. > That sounds similar to what Bill described. But, as I mentioned earlier, > Pivot doesn't define horizontal or vertical alignment properties on the > Component class. Layout customization properties are defined by the > container, not the child component. The only input a child component has into > the layout process is preferred size. > ImageViewSkin and LabelSkin already have "child" properties like this. So we have precedent. I implemented something similar in BorderSkin as an exercise. Pretty straightforward. I'm just waiting on the outcome of this discussion to see if I should check it in. I agree that this is (minor) violation of the DRY principle, but I like my libraries to have some redundancy, especially when it eases the life of client programmers. Regards, Noel.
