I had a similar idea a while ago after some struggles with ScrollPanes. I was thinking of a repository of sample layouts, possibly with an associated app to browse them. Something along the lines of ComponentExplorer, only for layouts, so a LayoutExplorer if you will.
Each layout example needn't be much more than a short description, screenshot and BXML file, but the screenshot/thumbnail could be automatically generated once the BXML had been rendered. A complimentary set of populated, sample components could be supplied as BXML files to be included (bxml:include) into the layouts in order to quickly visualize/prototype various scenarios. Think of them as a kind of Pivot Component 'Lorem Ipsum' library. Via some simple placeholders in the layout BXML files, the LayoutExplorer tool to could allow the user to quickly swap in various sample Components described above, or their own files. While this might be nice to have, I can now generally hack together my layouts without too much hassle, so couldn't justify the effort to get a prototype together. Chris On 18 March 2011 22:36, Roger Whitcomb <[email protected]> wrote: > Could I make a suggestion here? Could someone undertake to make a page on > the website (maybe part of Tutorials) that has a number of common use cases > (such as Greg is citing here) that has worked out BXML code that implements > each use case. Such a page could help reduce the number of > questions/complaints about layout. My apologies if someone has already done > this and I just missed it. > > ~Roger Whitcomb > > Sent from my iPhone > > > On Mar 18, 2011, at 7:41 AM, 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. >> >> >> >>
