Resizing the container layout does not re-layout the blocks

[inahas]

I have a responsive UI that resizes the container layout in increments of n*blockwidth.

When I resize the layout smaller, the items are re-laid out properly. However, when I make the layout wider, this does not always have any effect on the contents and they appear as one long column with plenty of space to the right.

Calling requestLayout does not fix the problem. Even removing and readding all the components does not fix it. It seems the layout still 'thinks' it is too narrow to fit more than one block horizontally.

The only workaround I found and using is to create a new MasonryLayout object and refill every time the size changes.

[alump]

Sorry for long response time. Does all components above MasonryLayout resize correctly? Please provide your component hierarchy above MasonryLayout.

[inahas]

It's been awhile. We've encountered other issues related to adding/removing/reordering individual components that we ended up using a general purpose solution: we simply remove/add all components everytime a change occurs.
As I recall when I logged this particular defect, the parent was resizing fine because we place the masonrylayout inside a panel which we deliberately size in increments of n * columnWidth and we could see the panel width changing.

[alump]

And Masonry inside panel had it's width set to 100%?

[inahas]

Looking at the current code, I don't see us explicitly setting any width for the masonryLayout. Just calling panel.setContent(masonryLayout). And the panel itself is set to a fixed width.

[alump]

That might be the issue. If size is left undefined it will size itself like that. If you do not define size for it, then it will at start size itself most likely correctly, but as parent allows scrolling, after that it will simply ignore all changes.

[inahas]

Hmm.. How come adding a component fixes it? This is what we currently do to work around this issue (and other add/remove issues):

    private Panel                               mBodyPanel;
    private MasonryLayout                       mBodyLayout;
    private CssLayout                           mMasonryLayoutBugFix        = new CssLayout();

... in constructor 
        mBodyPanel = new Panel();
        mBodyPanel.addStyleName(STYLE_PORT_CONFIG_PANEL);
        mBodyPanel.setSizeFull();
        mBodyLayout = new MasonryLayout(PanelConstants.BLOCK_WIDTH);
        mBodyPanel.setContent(mBodyLayout);
...

    // This is called anytime the window is resized
    public void handleResize(int newWidth)
    {
        mBodyPanel.setWidth(newWidth, Unit.PIXELS);
        forceRelayout();
    }

    private void forceRelayout()
    {
        mBodyLayout.removeComponent(mMasonryLayoutBugFix);
        mMasonryLayoutBugFix = new CssLayout();
        mBodyLayout.addComponent(mMasonryLayoutBugFix);
    }

[alump]

I think will do some re-layouting when child components change. And when it performs full relayout it will again use the parent size as target. If there are no changes in child component, then it will just accept size as it is. Maybe, I haven't really tested MasonryLayout well enough with undefined width.

[inahas]

The code above also fixes an issue with individual component resizing. Our blocks (components) can be collapsed/expanded by the user. Collapsing a block was not triggering the appropriate re-flow and leaving components with a blank space below them so we call forceLayout() to fix that too.

In general, it seems the method requestLayout() would've solved all these issues if it actually performed a re-layout as one would expect. However, it seems to have a mind of its own.

[inahas]

While I have you, let me add that in spite of these small issue it's an awesome add-on and we use it extensively in our application. Thanks.

[alump]

Thanks, I will try soon to write test case to simulate this issue, and then see if I could maybe make requestLayout to perform steps it now skips.