On Nov 21, 2007 1:53 PM, Havoc Pennington <[EMAIL PROTECTED]> wrote: > Hi, > > Matthias Clasen wrote: > > On Nov 20, 2007 8:45 PM, Behdad Esfahbod <[EMAIL PROTECTED]> wrote: > > > >> a) Maximize number of children taking their natural size. > > > > I am not convinced this is always the best strategy. Doesn't this > > encourage starving > > one child in favour of the rest of the pack getting their natural size > > ? If you really want > > to be flexible in this, you probably need to go to a TeX-like glue > > model and assign > > stretchabilities and shrinkabilities to children. > > > > The canonical example is an ellipsizable label, where the min size is > something like the size of one letter plus "...", and the natural size > is the entire label width (given the available height). > > So, if you have a box full of labels and get extra allocation above the > minimum size, you want to first show all text in all labels (give > everything its natural size) and then second add padding or spacing > (give things more than their natural size). > > What you don't want to do is add padding or spacing, while some labels > are still ellipsized. > > In the HippoCanvas comments I defined natural size as: > > The natural width should be thought of as the width at which > alignment (HIPPO_ALIGNMENT_START etc.) makes no difference but at > which nothing will be chopped off or wrapped. > > That is, natural size is roughly defined as the size at which we show > everything, but don't have any padding or spacing. It's "size that's > more important than padding and spacing" > > Clearly this is something that should be crisply defined in the GTK docs > when extended layout is added. > > Here is the comment from HippoCanvasBox on how its algorithm works; I am > too lazy to follow Behdad's pseudocode to see if it is equivalent ;-)
You can't do that, that's what I did ;-). > /* > If we have an allocation larger than our request (min width), we > distribute the space among children as follows: > 1) for each child below natural width, bring it up to its natural width > a) count children with a request still below their natural width > b) find the child with the smallest needed expansion to reach > natural width > and record this needed expansion > c) distribute among below-natural-width children the minimum of > (all space remaining to distribute) and > (smallest needed expansion times number of children to expand) > d) goto a) if children below natural width remain > 2) if extra space still remains, divide it equally among each child > with expand=true > In other words, children will always grow to their natural width > whether they are expand=true > or not. Below-natural-size children always grow before expand=true > children. Yes I think they are equivalent. > Various optimizations are obviously possible here (keep track of flags > for whether > we have any expandable / any natural!=minimum, for example). > > The PACK_IF_FITS children are done in a second pass after other children, > the if_fits flag indicates which pass this is. If if_fits=TRUE we need > to skip if_fits children that did not fit. Interesting. Do you think that will be useful to add to Gtk+? > > Havoc -- behdad http://behdad.org/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list