Am Dienstag, den 20.11.2007, 20:45 -0500 schrieb Behdad Esfahbod: > On Tue, 2007-11-20 at 20:09 -0500, Behdad Esfahbod wrote: > > On Tue, 2007-11-20 at 07:23 -0500, Mathias Hasselmann wrote: > > > > > > When a container widget got more space allocated than requested, it > > > considers the difference between natural and requested size of its > > > children to distribute that additional space, in relation to the child's > > > difference between natural and minimum-size. Let's use an example for > > > demonstration: > > > > > > Assume we have a container with two children. Both children request > > > a_min = b_min = 50 pixels as minimum size. The first child announces > > > a_nat = 100 pixels, the second announces b_nat = 200 pixels as > > > natural size. > > > > > > This gives a requested size of c_min = 100 pixels, and a natural > > > size of 300 pixels (c_nat) for the container. Now the container gets > > > allocated at a size of 200 pixels (c_cur). This are 100 pixels to > > > distribute (c_gap). > > > > > > So the first child gets: > > > > > > a_cur = a_min + c_gap * (a_nat - a_min) / (c_nat - c_nat) > > > = 50 + 100 * 50 / 200 > > > = 75 pixels. > > > > > > The second child gets: > > > > > > b_cur = b_min + b_gap * (b_nat - b_min) / (c_nat - c_nat) > > > = 50 + 100 * 150 / 200 > > > = 125 pixels. > > > > Something that Ryan brought up, and I was hoping that Havoc answer is > > that the above algorithm is not optimal, you can easily do better. > > Quoting Havoc's words: "bring smaller items up to natural size first". > > Read his entire "TEXT LAYOUT THAT WORKS PROPERLY?" post here: > > > > http://log.ometer.com/2006-10.html > > Without checking HippoCanvas's implementation, I think this is how it > should work: > > Say there are n child widgets c^0 .. c^{n-1}, let > > c^i_diff = c^i_nat - c^i_min > > We want to assign c^i_gap such that the sum of c^i_gap's is equal to > c_gap, the container's extra space to distribute. We only consider the > case that there's not enough space for all children to take their > natural size. The goals we want to achieve: > > a) Maximize number of children taking their natural size. > > b) The allocated size of children should be a continuous function of > c_gap. That is, increasing the container size by one pixel should never > make drastic changes in the distribution. > > > Goal a rules your current algorithm out as yours essentially keeps all > children off their natural size until there's enough room for all. > > Goal b means that you cannot start from the least child gap, fulfill > them and then distribute the remaining gap between the rest of the > children, because when enough gap becomes available for you to > accommodate one more natural child, the allocations jump > noncontinuously. > > This algorithm achieves both goals: Distribute gap to children equally > (not linearly) and not more than they need. That is: > > - Sort children with decreasing c^i_diff. Use child order in the > container to break ties.
I have some concerns that the sorting step changes the complexity class
for some containers from O(n) to O(n log n). On the other hand we have
O(n^2) in GtkTable already. So probably this doesn't hurt too much, I
guess.
> - Allocate like this:
>
> for (i = n - 1; i >= 0; i--)
> {
> double share = (double) c_gap / (i + 1);
>
> if (share >= c^i_diff)
> c^i_gap = c^i_diff;
> else
> c^i_gap = ceil (share);
>
> c_gap -= c^i_gap;
> }
>
So it sounds interesting to try. But as Matthias pointed out already,
the use of natural size information is an implementation detail. So the
question is, if I should try that variant before my code is merged.
> Something completely unrelated: now that you are adding extended layout
> features, should we switch to doubles or some fixed subpixel format for
> size negotiation? The idea being, making it easier to make Gtk+
> dpi-independent in the future.
From my observation late conversion to integer values could save some
pixels wasted due pessimistic rounding, which would be another
advantage.
Ciao,
Mathias
--
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
