Re: questions re: aux info, size request

[Tristan Van Berkom <tristanvb openismus com>]

On Sat, 2010-09-04 at 21:37 -0400, Havoc Pennington wrote:
> Hi,
> 
> several questions looking at this code,

Sorry it took me a while to answer this mail.

> 
> 1. I may be nuts but I really thought set_size_request() could reduce
> a size request below the widget's normal request, back in the day.
> However, won't this code allow set_size_request to *increase* min size
> only?
> 
> http://git.gnome.org/browse/gtk+/tree/gtk/gtksizerequest.c#n311
> 
> i.e.   cached_size->minimum_size = MAX (cached_size->minimum_size, group_size);
> 
> and cached_size->minimum_size is straight from the widget itself.
> 
> Am I reading something wrong or was this an intentional change or a bug?

Not intentional... my mistake/bug (I was not aware you could reduce
the base size request using set_size_request()).

> 
> 2. The use of AuxInfo in gtkscrolledwindow.c is weird weird weird
> 
> http://git.gnome.org/browse/gtk+/tree/gtk/gtkscrolledwindow.c#n1873
> 
> scrolledwindow uses the forced size request of the child (done with
> set_size_request) but does not use the actual size request of the
> child? what?
> 
> This appears to be ancient 12-year-old weirdness, see commit 0d15bc66,
> http://git.gnome.org/browse/gtk+/diff/gtk/gtkscrolledwindow.c?id=0d15bc6687e9a9718273a37b3d880f6526fa91ce
> 
> In an era of min size, I think we should declare this silly and just
> use the min size of the child. The commit introducing this seems to be
> in a world where "set_usize()" (the old set_size_request name) meant
> "user-explicitly-set size" instead of its current meaning of "minimum
> size request"

I agree its weird weird weird, the scrolled window hfw changes were
delicately effected in the hope of not breaking anything (granted,
completely reconsidering the scrolled window code would have been
better).

That being said the next thing on my list is to seriously
reconsider how scrolled windows should work with height-for-width 
(as my current patches for height-for-width treeviews has some 
evil hacks in place to avoid infinite recursions when placed
in scrolled windows).

For a taste of what's in store for scrolled windows you can
read through Owen's prior work here:
    https://bugzilla.gnome.org/show_bug.cgi?id=611740


> 3. The use of AuxInfo in gtklabel.c I don't really understand, plus seems buggy
> 
> Basically, in a w-for-h h-for-w world, why does label need to look at
> this itself and include it in its size request up front? I can imagine
> the motivation back in the days when wrapped labels had to be hacky,
> but now they should not have to be hacky. What is the story on this?
> 
> If it is used, the buggy is that it seems to ignore the GtkMisc
> padding etc. properties and assume that set_size_request only sets the
> size of the text itself, rather than the entire widget.

Right... again as with scrolled window I tried to make the least changes
as possible (originally I was hypothetically targeting GTK+ 2.x series).

Some good refactoring and even optimization is also possible in
gtklabel.c, the problem here is that everything is done through
gtk_label_ensure_layout() which is called way too often, recreating
the label's layout for the sake of any request.

That being said... we can probably safely just remove the bit
that consults aux_info from inside gtk_label_ensure_layout(), this
must be there historically so that gtk_label_ensure_layout() creates
a layout at the right height when doing a "size-request" for a
word-wrapping label.

Cheers,
         -Tristan