Dynamic height of FlowLayout

[matus_b]

Hi Isomorphic,

it will be nice if you can help us with the following problem: we need to use FlowLayout for showing Tiles of different widths. Tiles can be added or removed dynamically. FlowLayout width should be constant but the height has to adapt to content.

Setting overflow to CLIP_H throws following warning and it is set to VISIBLE instead, which results to extending FlowLayout width (and also it is somehow very slow).

WARN:FlowLayout:isc_FlowLayout_0:This widget has overflow specified as "clip_h". This overflow setting is not supported - defaulting to overflow:"visible"

In the attachment is modified BasicTilingSample from build (v8.3p_2014-02-24/LGPL Development Only (built 2014-02-24)), testing with FF.

Thank you

[Isomorphic]

Can you give a clearer description of what you want?

If you want clipping at a fixed width, you could just embed the FlowLayout into a container than is overflow:hidden or overflow:auto.

[matus_b]

I need overflowing at fixed width.

So adding tiles will make flowlayout higher, removing tiles will make it shorter but width will always stay as it is.

[Isomorphic]

Please try to be more specific.

The default behavior of a FlowLayout means that overflow will never occur unless a single tile (+ spacing settings) is larger than the configured width of the FlowLayout.

So is that scenario (one large tile) the scenario you are considering?

If so, what's the overflow behavior do you want?

And what specifically is wrong with the suggestion already given:

If you want clipping at a fixed width, you could just embed the FlowLayout into a container than is overflow:hidden or overflow:auto.

[matus_b]

So is that scenario (one large tile) the scenario you are considering?

No, in our scenario are many small tiles. Width of each tile is less than width of flowLayout, but sum of the widths is greater.

If so, what's the overflow behavior do you want?

Ok, better than describing is maybe to show it to you.

http://jsfiddle.net/PrimaMateria/dQU33/5/

In the example you can see how adding tiles is making flowLayout(red) higher and moving resultGrid down. Removing tiles has the exactly opposite effect.

In the attachments picture 'auto.png' shows overflow set to AUTO. When sum of tiles widths is more than width of flowLayout, tiles are shown on next row and the width of flowLayout is intact. That's right, but we don't want scroller and fixed height of flowLayout there.

Picture 'visible1.png' shows overflow set to VISIBLE. Before sum of tile widdths exceed flowLayout width everything is ok. After adding one more tile in 'visible2.png' you can see that flowLayout's width was increased. And there are some performance problems. I was not even able to take screenshot from FF as it was always freezing.

And what specifically is wrong with the suggestion already given?

I think, now you understand, that we don't need clipping at fixed width but overflowing on Y-axis at fixed width.

Thanks

[Isomorphic]

We see the "performance problem" you refer to, which is likely an unintended loop within the framework, and will investigate.

[Isomorphic]

We were able to make your (modified) sample stable by applying a slight change at the beginning of getViewPanel:

        final FlowLayout flowLayout = new FlowLayout();
        flowLayout.setBackgroundColor("#f99");
        flowLayout.setWidth(800);
        flowLayout.setOverflow(Overflow.VISIBLE);

//        flowLayout.setHeight(100);
//        flowLayout.setOverflow(Overflow.CLIP_H);
        
        flowLayout.setTiles(getRandomTiles());

That is, set the width explicitly to a fixed value, rather than having it size with the widget's parent, and then set the FlowLayout's overflow to VISIBLE. With these changes, you should get the behavior you want of expanding vertically based on the tile content.

Does this meet your requirements? The instability/performance issue you mentioned comes into play only when the FlowLayout width is set as "*" (or some perecentage of the parent) so that will need to be resolved before you can take that route (we're looking into that).

[matus_b]

Yes, this works! For now we will use this workaround with hardcoded widths and resize handler.

Please, let us know when you will resolve issue with "*" width.

Thx

[Isomorphic]

We've applied a fix to the SC 9.1p/SGWT 4.1p and SC 10.0d/SGWT 5.0d branches that should be in the next nightly builds.

[matus_b]

We've applied a fix to the SC 9.1p/SGWT 4.1p and SC 10.0d/SGWT 5.0d branches that should be in the next nightly builds.

We still use SGWT 3.1p :(
Is it possible to apply the fix there as well?

[Isomorphic]

We've ported the fix back to the SC 9.0p/SGWT 4.0p and SC 8.3p/SGWT 3.1p branches. Wait for the next nightlies.

[matus_b]

Hello again,
we are still using this solution, everything worked fine, but recently we have found out that when we are removing last Tile instead of the first one, the FlowLayout somehow doesn't realize that it should shrink.

Please, can u have look on this?

In the attachment is the modified example (just the remove button click handler was changed). I have tested it on SmartClient Version: v8.3p_2014-05-08/LGPL Development Only (built 2014-05-08)

[Isomorphic]

The problem you observed with FlowLayout was specific to SC 8.3p/SGWT 3.1p - the newer branches don't have the issue.

We've applied a fix to SC 8.3p/SGWT 3.1p that should be in the next nightly builds.

[matus_b]

Hi,
our tester just reported that 'last tile removing' issue is still present for IE browser (tested with IE9). Please, can you have a look?

[Isomorphic]

This issue has now also been addressed. Please download a new nightly build.