custom layout issue - header height

Hello,
I've created custom container layout (it's basically gridbag layout from java compiled to javascript). My layout needs to take into account height of docked items at top/bottom of panel, typically panel header. For some reason, header height is calculated only after it's width is set. This leads to layout failure in some cases.

As a temporary fix, I'm setting header width to some large constant number. Layout calculation doesn't get stuck then and it also considerably reduces layout cycles and therefore makes layout calculation faster. But diag.js gives me warnings - [W] BAD! P1_header.width set by P1<dock> and P1<ux.gridbag>.

My question is : why does header need to know it's width to calculate
it's height? It should need it, because "text-overflow: ellipsis;
white-space: nowrap; overflow: hidden" styles ensure, that header text
will always be single line and fit into header box.

My question is : why does header need to know it's width to calculate
it's height? It should need it, because "text-overflow: ellipsis;
white-space: nowrap; overflow: hidden" styles ensure, that header text
will always be single line and fit into header box.

The general situation is that text and what-not can wrap, so we wait for the width to be determined. We don't interrogate the CSS to determine if *all* markup in a component is free of wrapping, but there is a "noWrap" option (undocumented iirc) that can be used to tell the component layout about this... basically for the reasons you mention: fewer cycles and less waiting.

That said, from the sounds of things it appears that your layout may be not marking itself as unfinished (this.done = false) when values it needs aren't available. Either that or you are attempting to shrinkWrap width and something else isn't connecting properly.

Can you post the code of your custom layout? Simply setting noWrap may help in this test case, but it is hard to tell if it will be correct in general (so perhaps other use cases may still fail).

In general, to get a container layout spot-on, you need to be able to properly describe the way it will handle sizing of its items (getItemSizePolicy) and then make sure you handle you own size model combinations correctly as you calculate. It is an easy mistake to make thinking that the container layout is always in charge of sizing when in fact, it may depend on values from "outside" itself (configuration and/or ownerLayout).

I've compiled http://docs.oracle.com/javase/6/docs...BagLayout.html using GWT/gwt-exporter to javascript. Swing layout managers such as GridBagLayout need to know preferred size of child items. Preferred size of labels, form fields etc. is simply their natural size, for containers it is calculated recursively by layout algorithm.

First p1 calculates layout of it's content, then it adds size of docked items, that invalidates height (because panel header height is unknown), but width is still OK. Layout of pmain then sets width to p1 and the rest of layout is easily finished. Log of layout calculation is at http://pastebin.com/nZvKfQX6 .

Again p1 calculates layout of it's content, then it adds size of docked items, that invalidates height, but width is still OK. Because preferred size of p1 is unknown, p2 cannot calculate it's preferred size and that causes layout calculation to fail. Log of layout calculation is at http://pastebin.com/Z3CQbLUw.

Can I (or should I) set some attributes to panel header to indicate, that it's height doesn't depend on it's content?

I could solve this problem by separating width and height calculation in gridbag layout. But I would like to avoid doing that, because it shouldn't be necessary. In future, I may need to add another swing layout, in which separation of width and height calculation is not possible (for example http://docs.oracle.com/javase/6/docs...lowLayout.html ) .

Layout calculation succeeds, but log contains messages [W] BAD! f1.width set by f1<textfield> and main<ux.gridbag> . Textfield updates it's width to value set by ux.gridbag layout, but combobox does not. Log of layout calculation is at http://pastebin.com/zEUqN6bt. What's the best way to fix this issue?

What you are describing is similar in behavior to a Box layout (hbox and vbox) when "align" is set to "stretchmax". In fact, this is one of the most complex maneuvers in the layout system.

The key thing is that your layout both reads and writes the size of the children. You probably fully understand the write you need to do, but the read is when you request the component's "preferred size", which we would call its "shrinkWrap" size.

If the layout is going to calculate the size of a component, we do not waste time determining this value (it isn't free). The way you have this structured in your description, your layout is indicating that it will be calculating the size and that is the whole story.

In your calculate method, you'll want to make make sure that you know whether or not you are being called before the child has determined its size or after. The easiest thing to do would be to structure your calculations in 2 phases: 1) allow the children to determine their shrinkWrap size; 2) invalidate the children that need to change size based on your calculations.

Again, this is 2-step process is most tricky. I highly recommend you study the Box layout and its calculateStretchMax method.

To be of much more help, you'll probably need to post the layout class as you have it.