[PEAK] Some notes on trellis.ui.layout

[Phillip J. Eby]

At 02:29 PM 10/24/2007 +0300, Peter Damoc wrote:
>As for the documentation... other than the source code... I haven't 
>seen anything BUT... that's not the point... the idea of a 
>mini-language inside a text descriptor was the point... you can 
>invent one yourself... LEL is not famous enough to warrant a port.

Ah...  Basser Lout *is* such a language, and the long-term intent is 
to be able to use Python operators to implement such a mini-language.

The thing I'm looking for here is space allocation algorithms, like this:

http://www-bio3d-igbmc.u-strasbg.fr/~ripp/help/tcl8.5a1/html/TkCmd/grid.htm#M32

Although this too is a bit sketchy on certain details.  I've also not 
found any layout algorithms that allocate fractional pixels in such a 
way as to prevent rounding error accumulation.

Still, after some consideration, it seems to me that one could handle 
that part by accumulating a rounding error ala Bresenham's line 
drawing algorithm.  Something like:

    total = sum(weights)
    half = int(total/2)
    error = 0

    for weight in weights:
        size, remainder = divmod(weight * to_alloc, total)
        error += remainder
        if error >= half:
            size += 1
            error -= total
        yield size

For each item, we are effectively computing (weight/total) * 
to_alloc.  These (weight/total) fractions must sum to exactly 1, 
since total is the sum of the weights.  Thus, the remainders from 
each division must sum to a multiple of "total".  By checking the 
accumulated error against the halfway point rather than "total", we 
shift the error allocation towards the middle of the layout a bit, 
rather than always putting a single leftover pixel on the far right 
(or bottom).

Interestingly, this code appears to work correctly for both negative 
and positive values of to_alloc, so it's a reasonable primitive 
function to use for computing weighted size adjustments with no leftovers.

The broader algorithm, though, needs to use this calculation 
repeatedly in order to adjust the sizes of all the components being 
laid out.  And the details of that part still aren't defined yet.

(Also, the above algorithm needs to handle the situation where 
total==0, probably by creating an extra item with a weight of 1 so 
that the extra or missing space occurs at the right or 
bottom.  Actually, just changing the total to 1 might suffice to 
simply not adjust anything.)


>ooops....
>This is a common issues with the mailing lists that don't have the 
>"Reply-To" set to the mailing list address.
>I know for some there is a "proper" way of handling this with some 
>extra field in the messages handlers and smart enough clients BUT 
>most of us just click Reply and expect the message to arrive to the 
>list address.

See http://www.unicom.com/pw/reply-to-harmful.html, and look for the 
"Reply to all" or "Group reply" operation in your mail client.