Re: Extended Layout Summary

[Havoc Pennington <hp redhat com>]

Hi,

While I haven't looked at the patches in detail, based on your writeup 
it feels like the interfaces here will make it a little hard to 
implement in widgets.

In HippoCanvas I ended up with this:

> void (* get_width_request)    (HippoCanvasItem *canvas_item,
>                                int             *min_width_p,
>                                int             *natural_width_p);
> void (* get_height_request)   (HippoCanvasItem *canvas_item,
>                                int              for_width,
>                                int             *min_height_p,
>                                int             *natural_height_p);

(this API assumes height-for-width only, of course)

The most important thing here, I originally had separate 
get_natural_size and get_min_size. However, I found that often these two 
functions were the same, and when not the same, they had significant 
logic in common. So to do them separately I ended up creating the same 
PangoLayout twice for example, or else having to cache it, and I usually
had to awkwardly factor out a function shared by the two.

Note that I used the term "request" to mean both min and natural 
together, and then used min_size and natural_size for the specific 
request components; unfortunately for gtk, "request" already means 
"min", so the naming will have to be more confusing. Maybe "desired 
size" or something means "both min and natural"

What if the API for GTK+ were something like the above, plus a 
width-for-height variant, so rename the above two:

 get_desired_width(int*,int*)
 get_desired_height_for_width(int,int*,int*)

and add:

 get_desired_height(int*,int*)
 get_desired_width_for_height(int,int*,int*)

Then the following default implementations:

 - all four of the new functions have default implementations that
   invoke the current size_request and use it for both min and natural
   size; so unmodified widgets still support the new interface

 - the default implementation of size_request
   (gtk_widget_real_size_request) is modified to do something like

   if (widget has height-for-width feature) {
       get_desired_width(widget, &min_width, NULL);
       get_desired_height_for_width(widget, min_width, &min_height,
                                    NULL);
       requisition->width = min_width;
       requisition->height = min_height;
   }

With the above, to write a simple widget you would only have to 
implement two functions: get_desired_width() and 
get_desired_height_for_width().

The point is, in newly-written widgets ideally there is no need to code 
the now-deprecated size_request; and also for most widgets hopefully no 
need to implement width-for-height since that's something of a strange case.

There are a bunch of details here in exactly how the default 
implementations work, I probably got something wrong.

Another thing I'm not clear on from your mail is the padding stuff; 
basically, it looks like every widget implements padding support for 
itself. In that case, what's the point of having get_padding in the 
generic extended layout interface?

Starting from scratch as in HippoCanvas I think padding/margin/etc. 
should be done generically so all widgets automatically have them, and 
just as importantly, so no widgets ever have to do padding/margin 
calculations in their size request/allocation code. i.e. have the 
containers add the padding/margin on behalf of their children.

That's a bit tricky for GTK since there's legacy gunk in the way, but I 
think it's the ideal.

The question about this patch though is just, where is the get_padding 
call used generically, i.e. when does a widget get the padding for 
another widget of unknown type, rather than for itself which has known type.

As a very minor point, I'd make the padding guint16 not guint, which 
will save 64 bits per widget; in HippoCanvas I even went for guint8, but 
for GTK maybe that is too limiting. (Not that I've ever seen a padding 
that was even 64, let alone 256, but...)

Havoc