Unpacked box layout is f*cked
Charles Goodwin <[email protected]> Sun, 04 Apr 2004 02:56:54 +0000
| Newsgroups | gmane.comp.java.xwt.core |
|---|---|
| Organization | XWT Foundation |
| Message-ID | <[email protected]> |
When attempting to do layout similar to absolute boxes in Lithium, the
first place to look is apparently unpacked boxes.
Looking at the resizing algorithms in Box.java shows just how broken
unpacked box layout is.
For unpacked children, it goes like this...
First thing, Box.java works out the width of the columns said unpacked
box spans:
for(int i = child.col; i < child.col + child.colspan; i++)
unbounded += colWidth[i];
But wait... unpacked boxes are left completely out of the repacking
algorithm. They (should) never have a column assigned to them. The
repack() algorithm (both the original and a rewrite I did) used only
firstPackedChild() and nextPackedChild().
The rest of the algorithm, whilst less wierd, looks full of holes.
So I look to the reference at how unpacked boxes _should_ work. There
is only one paragraph that talks about unpacked placing:
"Non-packed boxes: each non-packed box is transformed according to the
parent s transform property and then positioned so that its alignment
point is (child.x, child.y) pixels from the parent s alignment point
(both alignment points are determined by the parent s align property)."
Well that currently doesn't happen... unpacked boxes are placed _after_
all their siblings and forcibly resizes a parent box.
Also, 'transform' is broken (/not yet working) so that's moot.
I'm guessing that the current implementation is utterly wrong. (I'm
left to guess since my other messages on the subject have been ignored.)
I'm gonna patch the core to make unpacked boxes behave as the reference
describes _plus_ I'm going to make parent boxes clip unpacked children
which is a big ambiguity in the current spec.
--
- Charlie
Charles Goodwin <[email protected]>
Online @ http://www.charlietech.com