FlowLayout
August 13, 2010
FlowLayout is a custom layout that arranges visual components in order, left-to-right, row by row, just like the words in a book. It works best arranging items with different widths (but the same height). When used with uniformly sized items, FlowLayout degenerates into a basic TileLayout.
Usage
<s:Group> ... <s:layout> <s:FlowLayout horizontalGap="4" verticalGap="8" /> </s:layout> </s:Group>
Params
- horizontalGap
- The horizontal space between the items in pixels.
- verticalGap
- The vertical space between the items in pixels.
- padding
- The spacing in pixels between all the boundaries of the container and the items within the container.
Sample
Flash is required. Get it here!
full screen | view source | download
Author
Layout & sample by Justin, based on example code by Evtim The Godfather Georgiv.
Bill
This is a great start. However, in my struggles to perfect a FlowLayout of my own, I’ve run into plenty of issues attempting to address all the functionality I require. I’m wondering if you have as well, or if you have even attempted to make a more powerful flowlayout.
For example, I would like a FlowLayout that works on Groups AND SkinnableContainers. For basic functionality, this seem to work, but I would expect that a good flowlayout will respect the maxWidth/maxHeight values of its target. For a simple Group, this is not a problem. But when you use this layout with a SkinnableContainer (in which case the layout is now acting on the contentGroup of the skin), you find that the contentGroup does not have the maxWidth/maxHeight values from its hostComponent. You could of course make the skin handle this by having it set the maxWidth/maxHeight values on its contentGroup, but the flowlayout would have to assume that any skin it is acting upon has been written this way. There are a ton of issues like this, mainly dealing with the problems of working with both Groups and SkinnableContainers.
Have you also found this to be the case? I’ve mainly attacked this problem by making the FlowLayout do some exploration of the target it is working against, but these resulting layout code is very brittle and it feels very hacky.
Jess
Seems like if you randomise the width and height, the layout no longer observes the vertical gap. Surely it should measure each row and position the next row according to the bottom bounds of the item with the greatest height plus the vertical gap. At the moment the items touch the ones in the row above.
justin
@Jess: Yes,
verticalGapis not respected. As of v0.5, it’s just using the height of the first element in the row for the height of the entire row, which is obviously incorrect.But that’s not all,
paddingis not correctly handled on the right and bottom of the container, and everything blows up if you try to put it inside a sparkScroller.Basically, there is still a lot of work to do to make this a well-tested, robust layout.
justin
As of v0.5.1, the
verticalGapissue is fixed and thepaddingis handled correctly. Alas,Scrollerstill causes instant death.Brian
Hey the layouts are awesome and helpful, but i think it would be useful to add RIGHT-TO-LEFT option in a future releases.
Thiago
Perfect exactly what I was looking for. Thanks
Evan
I’m having a problem trying to use
FlowLayoutwith aDataGroupin aVerticalLayout. The content that should be below theDataGroupthat’s using theFlowLayoutappears to overlap inside the content of theDataGroupitself.Here’s a mock up of what I’m trying to do: http://pastebin.com/sDXextYg
justin
@Evan: Try giving the
DataGroupawidthandheight, or aminWidthandminHeight, or aleft,right,top,bottom.FlowLayoutlikes know the container’s “size” so it can flow the contained visual elements.Check out the sample above — it’s view source enabled.