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