Re: the endless cycle of resizing

[Paul Davis <paul linuxaudiosystems com>]

i finally got time to look into this some more. i realized that it all
goes back to a quite different issue. the problem is/was that
GtkScrolledWindows don't behave when you tell them to never display a
scrollbar in either direction. they seem to have been written with the
assumption that NEVER,NEVER is an impossible or absurd combination.

but this situation can arise where you have several scrolled windows
that you want to control with a single scrollbar (via a shared or
multiple adjustments). that scrollbar might not even be one of the
ones directly associated with the ScrolledWindow.

consequently, i had to find another widget that had scrollable
functionality, and the only thing i could find was a GtkLayout. But a
Layout does not resize to fit its children, and so this doesn't work
very well if the Layout may need to adopt different sizes depending on
(say) user fonts or other run-time configuration. i tried to resize it
by called size_request() on its one and only child, then called
layout_set_size(), but this apparently didn't work as well as i need.

perhaps the ScrolledWindow in GTK+2 is better in this regard. any
thoughts on whether this is true?


>On Thu, Feb 20, 2003 at 10:22:47PM -0500, Paul Davis wrote:
>> this is an old problem i've had for about 2 years with GTK. i just
>> want to see if anyone has any new ideas for how to deal with it.
>> 
>> the problem arises when you put two widgets that both dynamically
>> resize themselves (to match the size of their contents) into a
>> box/table and tell them to fill it. what happens is a ping-ponging of
>> configure events and size requests - each time one of them changes it
>> size, it causes a configure event to go to the other, which causes a
>> new size request, and round and round it goes.
>> 
>> i need to find a way to stop this from happening. right now, i have
>> resorted (for 2 years or so) to using a Fixed as one of the widgets
>> precisely because it does not resize to show 100% of its
>> children. this fails as soon as something happens that causes the
>> children to not fit inside the allocated size of the Fixed - the
>> edge(s) of the children become invisible.
>> 
>> does anyone have any idea how to stop this?
>> 
>
>I don't think I understand the problem fully - is the issue that their
>contents keep changing?
>
>I don't see why there would be ping-ponging unless the size request of
>each one is changing very frequently (each time the size is requested,
>basically).
>
>Are you doing queue_resize() out of size request or size allocate?
>that would clearly cause an infinite loop issue.