Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
> 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
You mean do_size_request() in gtksizegroup.c, don't you?
gtk_widget_real_size_request just returns cached data since size groups
were introduced.
> 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);
This API would require to calculate the size of GtkLabel for at least
three times:
1) get_desired_width
2) get_desired_height_for_width with min_width
3a) get_desired_height_for_width with allocated width of the
parent in vertically aligned containers like GtkVBox
3b) get_desired_width_for_height with allocated height of the
parent in horizontally aligned containers like GtkHBox
Why is it sensible to calculate the size three times?
Wouldn't it be better to replace size_request with
void get_desired_size (GtkRequisition *minimum,
GtkRequisition *natural);
Your get_desired_height_for_width and get_desired_width_for_height
functions would keep the signature you suggested (expect that I'd drop
the word "desired").
I cannot imagine situations, where you are without size restrictions,
but cannot trivially retrieve the other dimensions of a desired size.
So we really should calculate both dimension in one single step.
> 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.
How to react when a library user adds a handler to size-request signal
of a modern widget? Simply ignore it? Would be quite nasty if each
implementation of get_desired_size would have to emit and handle that
signal.
> That's a bit tricky for GTK since there's legacy gunk in the way, but I
> think it's the ideal.
That comment was directed to the padding stuff, we do not discuss right
now. Nevertheless it's also right for the new size request. Specially
since size groups were hacked in at some point in history. That's why
I've chosen the less ambitious way of adding a simple "get_natural_size"
method: Less interaction with legacy code.
Ciao,
Mathias
--
Mathias Hasselmann <mathias hasselmann gmx de>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil