a step towards solving align

[Adam Megacz]

I just realized that with the current formulation of the grid rules,
we can promise that the sum of the columns of a parent are always *at
least* as wide as the parent itself. Sometimes they're larger (due to
minwidths), but never smaller.

This means that the alignment of a box has no effect on the
alignment/size of the columns. So we can do alignment as a completely
separate step *after* sizing has finished!

- a

[Charles Goodwin]

Post by Adam Megacz
I just realized that with the current formulation of the grid rules,
we can promise that the sum of the columns of a parent are always *at
least* as wide as the parent itself. Sometimes they're larger (due to
minwidths), but never smaller.

Hmm. I'm unsure about this. I don't think it is right to hand out
slack to columns/rows whose maxwidth/maxheight have been reached. But
then, how does the layout account for child boxen that form a grid
smaller than the parent?

I said 'align centrally' which leaves the developer having to either
introduce sibling boxes (and extra rows/columns) to take up the slack of
to use a shrink-wrap-box to control the alignment.

I guess if we just make it mandatory that the slack is given out, then
we just reduce it the problem to the developer adding sibling boxes to
take up the slack or putting shrink=true to the box and aligning.

Sounds good to me.

Post by Adam Megacz
This means that the alignment of a box has no effect on the
alignment/size of the columns. So we can do alignment as a completely
separate step *after* sizing has finished!

The alignment of a box _never_ an had effect on the size of the columns.
Doing alignment after column/row sizing is the way it is current
implemented in the non-simplex core; as you implemented it.

[Adam Megacz]

Post by Charles Goodwin
Hmm. I'm unsure about this. I don't think it is right to hand out
slack to columns/rows whose maxwidth/maxheight have been reached. But

This will only happen when maxwidth has been reached for *all*
columns. In other word, no column goes above maxwidth until all of
them have reached it.

Post by Charles Goodwin
then, how does the layout account for child boxen that form a grid
smaller than the parent?

You just add a shrink box between the parent and its children.

Post by Charles Goodwin
to use a shrink-wrap-box to control the alignment.

Bingo. In general this is the new philosophy with Nitrogen; "boxes
are cheap" so often the right way to solve a problem is to add a box
or two.

Post by Charles Goodwin
I guess if we just make it mandatory that the slack is given out, then
we just reduce it the problem to the developer adding sibling boxes to
take up the slack or putting shrink=true to the box and aligning.

Yep!

Post by Charles Goodwin
The alignment of a box _never_ an had effect on the size of the columns.

Well, er, like I said, there was that confusing case about conflicting
aliginments. I never got a serious answer on why the description we
had would specify the behavior that "made sense".

- a

[Charles Goodwin]

Post by Adam Megacz
Well, er, like I said, there was that confusing case about conflicting
aliginments. I never got a serious answer on why the description we
had would specify the behavior that "made sense".

Columns sizes are (and should be) unaffected by alignment. Period. If
it were not like that, it would be unintuitive; too many factors
affecting box layout. Alignment should only affect a box's position
within free space around the box.

This way you only need to take boxes sizes into account when sizing
columns, which is not just simple for the core but simple for the Ibex
application developer to visualise (which is very important).

[Charles Goodwin]

Post by Adam Megacz
This means that the alignment of a box has no effect on the
alignment/size of the columns. So we can do alignment as a completely
separate step *after* sizing has finished!

Did we ever reach a decision on whether align was a per-child or a
by-parent definition?

I'm a per-child advocate personally.

[Charles Goodwin]

Post by Charles Goodwin
Did we ever reach a decision on whether align was a per-child or a
by-parent definition?
I'm a per-child advocate personally.

Adam, is it me or did you actually do this with unpacked boxes (probably
accidentally) from the start?

Lines 365/366 of latest Box.java:

child_x = child.ax + (child.test(ALIGN_RIGHT) ?
gap_x : !child.test(ALIGN_LEFT) ? gap_x / 2 : 0);
child_y = child.ay + (child.test(ALIGN_BOTTOM) ?
gap_y : !child.test(ALIGN_TOP) ? gap_y / 2 : 0);

[Adam Megacz]

Yeah, we're now going per-child.

Post by Charles Goodwin
Adam, is it me or did you actually do this with unpacked boxes (probably
accidentally) from the start?
child_x = child.ax + (child.test(ALIGN_RIGHT) ?
gap_x : !child.test(ALIGN_LEFT) ? gap_x / 2 : 0);
child_y = child.ay + (child.test(ALIGN_BOTTOM) ?
gap_y : !child.test(ALIGN_TOP) ? gap_y / 2 : 0);
--
- Charlie
_______________________________________________
core mailing list
http://lists.xwt.org/listinfo/core