Re: Bug in get_preferred_height_for_width() [was Re: Minimum height for minimum width]

[Tristan Van Berkom <tristanvb openismus com>]

On Fri, 2010-10-15 at 09:55 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Fri, Oct 15, 2010 at 8:55 AM, Tristan Van Berkom
> <tristanvb openismus com> wrote:
> > The for_size fed to widget implementations additionally needs to
> > strip the added padding that can happen in ->adjust_size_request()
> 
> Right, adjust_size_allocation should basically invert anything
> adjust_size_request does so the widget is seeing things as if only the
> widget itself had set the request.
> 
> By "padding" I don't just mean the margin properties, I mean anything
> adjust_size_request adds (also the padding for fill alignment, the
> container border width, etc.)
> 
> > However the bug I'm referring to is another one; the for_size also
> > needs to be limited to the natural size in the case that the widget
> > does not "fill" (i.e. not to compensate for pixels stripped in
> > ->adjust_size_request(), but for pixels that will further be stripped
> > in ->adjust_size_allocation(), in the case that the widget expanded).
> 
> Wouldn't it fix this to do adjust_size_allocation on the for_size?
> 
> > In the end the adjust_size_allocation() api/vfunc
> > will look like this:
> >
> > void gtk_widget_adjust_allocated_size (GtkWidget *widget,
> >                                       GtkOrientation orientation,
> >                                       gint           proposed_size,
> >                                       gint           natural_size,
> >                                       gint          *offset,
> >                                       gint          *adjusted_size);
> 
> If you have a for_size (which can be -1 for unset) then you could skip
> the natural size and just call the size request API again, using the
> for_size if >= 0. I think that would be better, because as you say:
> 
> > The part that feels weird here is that we are feeding in the
> > natural_size, however it's important because come allocation time
> > specifically; the 'natural_size' may be in context to a for_size
> > in the other orientation (i.e. the widget cannot be expected to
> > just "know" its natural size in this stage).
> 
> I think you should just call the request methods again. (Not the
> wrappers of course, the vfuncs directly.) Instead of passing in a
> natural size.

It needs to:

  a.) call the wrappers to get a natural_width before entering
      adjust_size_allocation(for_size, natural_width) so as to pick 
      up a good cached value that was treated by sizegroups and by
      adjust_size_request()

  b.) feed a natural size vs a proposed size to the
      adjust_size_allocation() because as I mentioned above: at
      allocation time, a widget cannot know its natural size, since
      it's natural size can be contextual to its dimension in the
      other orientation.

      Otherwise when doing valign at allocate time, the implementation
      calls get_preferred_height () ? no it cant because it's height
      already depends on its already allocated width (I recently fixed
      gtk_widget_real_adjust_natural_allocation() since it was calling 
      gtk_widget_get_preferred_size(), which results in vertically
      clipped labels when valigned CENTER).

So the convenience function that calls the new
gtk_widget_adjust_size_allocation(), clearly has to do the right
contextual request that gtk_widget_real_adjust_size_allocation()
does now (i.e. not the one it was doing 2 weeks ago)... the 
orientation contextual adjust_size_allocation()... needs to be
told what is the natural size... it has no context to make a guess.

Sorry, but this really is as complex as it seems... 

-Tristan

> 
> Havoc