Re: problems with GtkPaned and allocation/set_position

[Paul Davis <paul linuxaudiosystems com>]

[ Owen - I missed this while I was away, but dug it out the archive ]

>I'm not sure what you mean by "allocated a final size". Most programs
>allocate each widget only once when a window is initially shown,

my code traces at least 3 calls to size_allocate() for a given
Paned. it happens, as far as i can tell, as a whole bunch of resizings
take place as various scrolled windows adapt to their contents, which
are added after the paneds are first sized.

>and I'm pretty sure GtkPaned handles set_position() before 
>size_allocate() fine.

it doesn't if the position is larger than the initial allocation. what
happens is that gtk_paned_compute_position() uses the current
allocation as the max position, and ends up setting paned->child1_size
based on it. since child1_size is the only place where the requested
position is ever stored, its then lost for ever, so to speak.

if the position will fit into the *eventual* allocation, but don't fit
into the current allocation, you lose the requested position.

>If widgets are getting allocated to a tiny size before they get their
>final size, then you are probably doing something funny in your app.

well, i'm adding stuff to the window later, and the allocation for
existing widgets (including several scrolled windows and paneds)
changes because of the fill/expand settings i used when packing them.

>It might be possible to treat the set position as "virtual" and 
>never clamp it, I might even take a patch to do that, though I'd be
>worried that it would look bizarre to the user if the paned was
>clamped to the right edge, they resized the window bigger, and the
>paned stayed clamped to the right edge.

personally, i'd prefer gtk_paned_set_percentage(), which didn't use a
hard position at all. to fix set_position() for these cases, paned's
should leave the requested position untouched at all times. if the
allocated size grows, then one child will benefit (could be either
one, depending on how the paned was packed and how the window is
stretched.

>But I don't think it should be necessary in most cases, and I'd like to
>see an test case of where things don't work first.

that might be tricky to come up with. i'm in the middle of the release
road map for ardour, and to create an example, i'd have to spend a
while coding up some fairly complex box packing+run-time widget
addition. 

do you really believe that size_allocate() is only called once?

--p