Vaadin 7 RC1 layout problems

Hi,

Am I the only one whose layouts got totally crazy with RC1?

My application has basically one full sized VerticalLayout that contains the rest of the components, which vary a lot. I should never be able to see the browser scrollbars then, but I do. I get specially weird results with full sized panels…

I have gone through all the betas and no problems. Also the analyze feature says there are no errors…

Do I need to change my code or is it a bug?

Thanks

No, you’re not the only one.

Our layouts have totally gone south too. Both stuff with custom styles as well as standard layouts. Scrollbars everywhere, entire layouts collapsed and so on.
We hoped clearing old CSS in the browser cache would fix it. It didn’t. (Chrome/FF)

I wish we had not trusted them when they claimed 7.0 was to be ready on September 30th. It’s been four months of problems trying to catch up with bugs and continuous modifications which broke code we just had (painfully) put together.
Had they stated clearly back then that they were months away from some sort of stability, we would have waited, but then again, back in October it looked like 7.0 was just “behind the corner” so we trusted them and started developing with 7.0. Big mistake.

I’ll never try “beta” stuff from Vaadin again, that’s for sure.

(and please don’t come saying “if you have a problem please file a ticket”, because looking at how all our pages - perfectly working with beta11 - are now broken with rc1, I’d say that we’d have to file something like 10 tickets just to get it look remotely correct. I wouldn’t even know where to start. HorizontalLayouts for sure no longer work at all, no matter the width. Tables, margins… it’s a disaster).

It’s good to know I am not the only one…

Please take a look at this code. It is pretty similar to what I have in my application:


/**
 * The Application's "main" class
 */
@SuppressWarnings("serial")
public class MyVaadinUI extends UI {

    @Override
    protected void init(VaadinRequest request) {

        final HorizontalLayout layout = new HorizontalLayout();
        layout.setSizeFull();
        layout.setMargin(true);
        layout.setSpacing(true);
        setContent(layout);

        Panel panel1 = new Panel();
        panel1.setSizeFull();
        VerticalLayout verticalLayout1 = new VerticalLayout();
        verticalLayout1.setSizeFull();
        Tree tree = new Tree();
        tree.setSizeFull();
        tree.setContainerDataSource(new BeanItemContainer<String>(String.class));
        String a = "aaaaaaaaaaaaaaaaaaaaaaaa";
        String b = "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb";
        String c = "ccccccccccccccccccccccccccccccccccccccccccccccccc";
        tree.addItem(a);
        tree.addItem(b);
        tree.addItem(c);
        tree.setChildrenAllowed(a, true);
        tree.setChildrenAllowed(b, true);
        tree.setParent(b, a);
        tree.setParent(c, b);
        verticalLayout1.addComponent(tree);
        panel1.setContent(verticalLayout1);
        layout.addComponent(panel1);

        final Panel panel2 = new Panel();
        panel2.setSizeFull();

        layout.addComponent(panel2);
        layout.setExpandRatio(panel2, 1);

    }

}

There are 2 panel inside a Vertical Layout that fills the page. Both full sized but panel 2 has the expand ratio set to 1, so it should occupy as much space as he can.

In beta11 and previous it worked fine with no scrollbars but not the second panel does not shrink, and it actually has the size of the full page.

We´re having severe layout problems with rc1 and Runo theme, too. Especially it seems that whenever there are components without a fixed size inside a layout, it happens that these and other components placed inside the layout are rendered partly OUTSIDE the containing layout.

Our application was looking very funny - took me several hours of work to do all the workarounds.

Sorry, but in my opinion rc1 should be renamed to beta12.

Expand ratios seem completely broken.
Layouts with undefined height expand/collapse randomly unless you set it to fixed height.
We use this stuff basically everywhere, 75% of our application looks devastated.

No point in even trying to workaround this mess.
Especially since rc2 (and then rc3, rc4, etc. up until the release sometime in March) will likely change everything again. More fun ahead.

We’re back to beta11 until they release 7.0.0 (or maybe 7.0.1) and they’re bound to stop toying with layouts and fix all the regressions they introduce. Layouting work should have been completed since alpha1
one year ago
and be rock solid by now.

I am sorry to hear about all the problems with layouts and RC. Thanks for important heads up.

(And yes - the whole schedule of Vaadin 7 has been really slippery slope. We clearly tried to squeeze in too many changes in one release)

In my personal opinion it’s not nice to change the behavior of expand ratios such late in the game and it’s unfortunate.

However in your example, the panel1 should have undefined width and panel2 100% width. And then set the expand 1 to panel2.

Hi guys,

Thanks for reporting the issues you are facing. This enables us to create a better product for everybody.

There is a layout change in RC1 concerning invalid layouts and unfortunately “analyze layouts” does not detect these invalid layouts. The case is where you have two 100% wide components inside e.g. a fixed width HorizontalLayout and set expand to 1 for one of them and 0 (or leave the default 0) for the other. The expected behavior would be the way it works in Vaadin 6, i.e. the one with expand 1 uses all the space and the one with expand 0 becomes invisible (0px width).

Now in 7.0.0.rc1 this invalid layout is rendered so that the expand=0 component is visible with the intent that you can see more easily that you did a mistake when creating the layout. This, in combination with the 100% wide (expand=1) component, causes the parent layout to be wider than you would expect, which in turn can cause scrollbars in its parent. As this seems to be very confusing to a lot of people, and some seem to even use the feature as a way to hide components, I think we need to revert this change and continue to render expand=0,width=x% with zero width and ensure that analyze layouts warns about this (see
#10783
and
#10792
).

Based on the posts in this thread I’m not 100% sure if this is the only problem you are facing or not. We will revert the behavior asap and build a new snapshot. Would be good if you were able to test the snapshot and see if it solves the problems or not.

Hi all. We too experienced similar pain points especially with a big change in addons architecture and changes to locking. However it was our choice to code to beta software. Stable in beta, i always take it with grain of salt. They are least open to feedback and fixing issues for us. A huge change like vaadin 7 is complicated so let’s cut them some slack. I am sure they will reflect on this to improve on some things and forge ahead to do what is best for framework.

Our choice was to stay with 6.8 and adopt 7.0 as late as possible, if possible just 1 or 2 weeks before release.
That was back in late October, when the target release date was… October (as per their official roadmap page).
So we didn’t actually choose to code to alpha/beta software, quite the opposite.

And nobody here expects 100% stability in pre-release software. But if you announce plans of an imminent release and then drag it for 3-4 more months, companies who made business decisions based on those plans end up being royally screwed. We have deadlines and we can’t just say “oh, I’m sorry guys” to the customer.
I can certainly cut them some slack for 1 or 2 weeks delay, because that’s normal - we even accounted for this… but not for 4 months, especially if they use that extra time to keep changing behavior instead of just bugfixing frozen code.
This is just bad release management and communication.

What’s the point of giving estimate dates if you ignore them?
What’s the point of planning features if you push them away constantly?
(see e.g. the much needed new Table, from 7.0 it already got pushed to 7.2, i.e. almost a full year)

Yes definitely not happy push and new table didn’t make it in.

Folks, recently I migrated two proto projects from beta 9 to rc1. This is after trying out beta 10 and having to revert back to 9 to continue working without back-filling against a moving target. With rc1, all my layouts look screwed up and require modification. One screen is now entirely blank. I don’t want to do and re-do laying out screens and adjusting layout helper methods repeatedly.

Now, I know that there’ve been some scheduling challenges, and I’m acutely aware that I’m not (yet) representing a paying customer. However, is there any way we can get some reliable clarity on when the layout behavior can be finalized? I’m afraid I don’t have the luxury of spending time re-coding layouts, especially since my apps require custom themes and a lot of CustomLayout in order to fly.

Many thanks for everything,
Elliott

There were a lot of problems with horizontal and vertical layout still in beta11, mostly related to the layouts being rendered differently depending on whether it was the initial rendering or if the layout was updated. You can see these kind of problems if you use ?debug, press the analyze layouts button and this causes the layout to render differently.

If you want to test the layouts and how they behave, you might have some help by
http://demo.vaadin.com/tests-7.0.0.beta11/run/OrderedLayoutCases?debug&restartApplication
and
http://demo.vaadin.com/tests-7.0.0.rc1/run/OrderedLayoutCases?debug&restartApplication
. These tests can be configured dynamically so you can see how the layouts behave. (Press analyze layouts every now and then if you test beta11).

We are currently working to fix (revert behavior from rc1 to beta11 for)
#10783
. This should fix most, if not all, of the layout problems introduced in RC1. I was hoping it would be in the next nightly for you guys to test out but it seems you will have to wait another day.

If you have a case where the problems are not caused by a component with expandRatio=0 being shown when it should not, please create a ticket for the problem or post a test here as we can’t fix problems we are not aware of.

Apart from #10783, we are not planning any more changes for 7.0.0

Artur, really appreciate the candid and specific reply and very happy to hear fixes are imminent. I’ll try the update as soon as I see it’s available. For reasons to do with an accumulated sleep debt, shall just wait to see what might still be wiggy after the fix is applied. :slight_smile:

The fix is now included in the latest snapshot-version. Please test and report if you are still having layout issues with this version.

Ok, RC2 is out.

Now, can somebody please tell me how do I achieve exactly the same result as the one that I would get with that code in the 11 betas?

I need my left panel to occupy only the necessary space (the minimal). The tree inside sets the width.

My right panel occupies the rest of the remaining space.

In RC2 since the second panel has the expand ratio set to 1, it occupies the whole space. Tell me, why would I want that??

Set the width to undefined instead of 100%