On Tue, 2004-10-12 at 22:15 +0200, Tim Janik wrote: > GTK_RESIZE_IMMEDIATE. > 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 places. > - 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. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part