Re: Extended Layout Summary


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:


and add:


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,
       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...)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]