Re: changing usize in ::size-request (bug #155139)

On Tue, 2004-10-12 at 18:04 +0200, Tim Janik wrote:

> that is, in the label's ::size-request handler tab_label_size_request_cb()
> (at which point the label itself has already been size requested), the
> testcase unconditionally sets the label's usize. that in turn queues a
> new resize on the label.
> however, due to the handling of the ::size-request signal inside
> gtk, this request is later forgotten about (gtksizegroup.c):
> >       g_signal_emit_by_name (widget,
> >                              "size_request",
> >                              &widget->requisition);
> > 

How does this actually cause drawing to break? Is the problem that the
requisition of the label is changing without a new call to 
gtk_label_size_request()? I don't see how that would matter, offhand.

> basically, gtk doesn't support queueing new size requests from
> ::size-request, and that's been that way for a looong time.
> [owen: FYI, applying my if (GTK_WIDGET_REQUEST_NEEDED (widget))
>   gtk_widget_size_request (widget); fix from last week did indeed trigger an
>   endless resizing loop with the test case and without the set_usize() guards.]
> the bug at hand can fairly easily be circumvented in gtk by not queueing a
> resize from set_usize() if the new usize doesn't actually change anything.
> since this is a reasonable efficiency improvement to make anyway,

Yeah, looks good. (Though not understanding the problem, I don't
understand how it fixes it.)

>  i've
> comitted the appropriate guards to gtk_widget_set_usize_internal(). it
> doesn't fix the more fundamental problem of people wanting to adjust widget
> sizes around size requisition time though.

What's the use case? Generally, I'd expect the example to use:

    gtk_widget_set_size_request (label, label_width, -1); 	 

    *requisition.width = label_width;

This won't actually work because it will break GtkLabel's alignment
code, but you could introduce an intermediate container and get it to

> ideally, the ::size-request signal would be RUN_LAST. it's not,
> due to historic reasons though, and i'm afraid making it RUN_LAST
> will significantly affect signal connections in exiting code:

Yeah, I don't think we could do that compatibly.

> so in order to deal with widget size adjustments around ::size-request time,
> i see these possibilities:
> 1) make ::size-request a RUN_LAST signal as it ought to be. this should only
>     be done, when people are willing to put some work into porting their
>     applications to a new gtk+ version anyway, e.g. around gtk+-3.0.
> 2) introduce a ::custom-size or similar signal that is emitted directly
>     before ::size-request, and can be used by users to setup resizing handler
>     connections like the above (tab_label_size_request_cb, example_size_request_handler).
> 3) preserve the current state of affairs, where size adjustments that queue
>     a new resize during ::size-request are simply not supported.
> 4) make ::size-request a NO_RECURSE signal, and introduce a new private flag for
>     widgets (or similar mechanism like a private in-request widget list), which
>     can be used to detect queueing resizes during emission of ::size-request.
>     in that case, gtk_widget_queue_resize() could simply emit_by_name (widget,
>     "size-request"); which will cause a the current emission of ::size-request
>     to be restarted after the user handler queueing a resize returned.
>     that is, make ::size-request deal with recursive resize requests the way we
>     handle GtkAdjustment::value-changed.
>     this may still be incompatible with some existing user code setups, but
>     hopefully less so than simply making ::size-request RUN_LAST and as a
>     consequence, the caveats from (1) about applying this around a 3.0 change
>     only probably apply here as well.
> for the first three cases, it might actually make sense to add some magic to the
> signal code, to issue a warning once per runtime, for !AFTER signal connections
> to ::size-request.

I'd like to get a clearer idea of what we are trying to support before
commenting on the above. To some extent it would be nice to simply
support calls to queue_resize() at any point. But really changing the
size of a widget in response to size_request() is pretty odd.


Attachment: signature.asc
Description: This is a digitally signed message part

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