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

On Tue, 2004-10-12 at 22:15 +0200, Tim Janik wrote:

> i don't think things will continue to work as smoothly, if one of your
> resize containers is an immediate resize container and you queue a resize
> from within ::size-request of one of its children.
> so some of my suggestions (esp. (4)) tried to implement proper recursion
> handling from within ::size-request.
> come to think of it, i'm now pretty sure gtksizegroup.c implicitely depends
> on asyncronous resizes as well though.

Hmm, I don't actually see a problem. Combining RESIZE_IMMEDIATE with 
resize handlers that queue resizes definitely causes some complex
interactions, but mentally walking through a few cases, they seem fine.

I agree on gtksizegroup.c - the code that propagates queued resizes to
other widgets in the size group not going to work if queuing a resize
starts actually causing resizes. (You might be able to make it work by
carefully ordering the queue_resizes(). Doubt its a good use of
anybody's time.)

> >> mundane cases can easily be constructed where such circular scenarios either:
> >> - loop endlessly due to ping-pong size requests (the lable<->window dependancy might
> >>    request alternating sizes like: 4,5,4,5,4,5,4,5), or
> >> - get into a feedback loop (with size requests: 8,...,256,...,65536,...)
> >> and due to float-round-off, font-sizes, theme settings, etc. these pathologic cases
> >> might not even always be triggered.
> >>
> >> if we want to completely prevent such scenarios, i might even add:
> >> (6) explicitely catch queue_resize() during ::size-request emissions by a mechanism
> >>      similar to that suggested in (4), and issue a warning.
> >>
> >> i think we should stop to look for more use cases for queue_resize() from ::size-request
> >> though. experience shows that code is usually used in unintended or not planned for
> >> ways, so we should rather make a general decision on how to deal with recursive resize
> >> requests, than to focus on getting arbitrary cases to work and ignore others.
> >
> > I think we should give people the rope ... yes, calling queue_resize()
> > out of ::size-request or ::size-allocate can easily trigger loops, but
> > especially when the entire window content is known, it can be safe and
> > useful in cases... you can use it to emulate height-for-width for a
> > widget, for example.
> ok, for 2.6, i'd sugegst we then do:
> - unsetting the GTK_REQUEST_NEEDED flag before we emit ::size-request, as you suggest
> - deprecate GTK_RESIZE_IMMEDIATE and internally treat it as GTK_RESIZE_QUEUE
>    (if somebody would really wanted to shoot himself into the foot with immediate
>    resizing, he can still call gtk_container_check_resize() himself)

Deprecating it sounds like a good idea, but while deprecating it I'd
probably leave the code as it - if someone is using it, it's probably
working fine in their application, even if it falls over in other

> - leave the
>      s/while (!GTK_WIDGET_ALLOC_NEEDED (widget) ||
>               !GTK_WIDGET_REQUEST_NEEDED (widget))/while (TRUE)/
>    change from 2.4 in place. while it shouldn't strictly be neccessary, the
>    checks aren't strictly necessary either and simply "set ALLOC_NEEDED and
>    REQUEST_NEEDED up to the resize_container" is easier to read and understand.

Yeah. It was added to turn a O(n_widgets * depth) operation into a O(n)
operation, but since finding the resize container already makes the
overall cost O(n_widgets * depth), there's really not a lot of point.


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]