Perhaps I'm not explaining myself clearly. Currently, when a Label is inside a BoxPane, and fill==false, the Label will never wrap, which is a little odd, particularly when there is available space. I want to create a BoxPane, where orientation==vertical and fill==false, but components are allowed to size themselves vertically within the available width.
On the Border front, I want to be able create a Border around an ImageView, and then place that Border inside a BoxPane, and tell the Border that it should not fill the available space, but instead align itself within that available space. This is consistent with how Label and ImageView work. So really, what I'm saying is that we should extend functionality that is available inside Label to Label's that are inside a Border object. -- Noel. On Fri, Mar 18, 2011 at 16:41, Greg Brown <[email protected]> wrote: >>> 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. > > How is that different from the current behavior? That's exactly what "fill" > does. > >>> 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. > > Maybe I misunderstood your suggestion: > >>>> Alignment and fill would affect how the bordered component sits within the >>>> space allocated by the parent container. > > What is "the parent container" in this case? If it is the Border itself, then > yes, those properties would be consistent with ImageView, Label, Border, etc. > But that brings me back to my previous point - I don't think the use case for > customizing alignment within a Border is particularly strong. There are two > primary use cases for a Border: > > 1) You want the content to fill the border's bounds, and you want the border > to grow/shrink with the content's preferred size. > > 2) You want the border to have some fixed size, and you want the content to > be scrollable if it exceeds the size of the border. > > In case #1, an alignment style would be useless since it would always be > ignored. In case #2, you'll need to put a scroll pane in the border and make > the actual content a child of the scroll pane, so the alignment styles would > be ignored here too. > > >
