Re: questions re: aux info, size request

[Tristan Van Berkom <tristanvb openismus com>]

On Tue, 2010-09-07 at 14:44 +0900, Tristan Van Berkom wrote:
> 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()).

However now that I give this one some more thought, I wonder if this
has been somehow broken for a while now.

For instance... when you put some widgets into a GtkSizeGroup and
explicitly set one of the widgets minimum size to a smaller value
than the others - will it's minimum size not still grow to match
the largest minimum size in the group ? (should it have worked the
other way around and shrank all other widgets in the group for 
an explicit "small" request ?).

What is the behaviour that we want here ?

Personally I'd like to think that:
  - You cannot allocate any widget a size smaller than its minimum
    request without expecting breakage 
    (see never ending thread on
     https://bugzilla.gnome.org/show_bug.cgi?id=617442).

  - Setting an explicit minimum request with
    gtk_widget_set_size_request() guarantees that it will never be
    allocated a smaller size than the one the user specified
    (currently though; the docs mention you can adjust the size
    request to be smaller without any guarantee that it will
    actually be allocated such a small size).

What is the use-case for forcing a widget to request something smaller
than it's content ?

Cheers,
        -Tristan

> 
> > 
> > 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
> 
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list