Re: Strange window resizing behaviour in Gtk+-2.0

[Havoc Pennington <hp redhat com>]

Nicholas Allen - Sun Ireland - Software Engineer <nicholas allen ireland sun com> writes: 
> /* Programatically change the size of the window. What actually
> happens is that the button is resized but not the window!*/
>  bounds.x = 100;
>   bounds.y = 100;
>   bounds.width = 500;
>   bounds.height = 500;
>   gtk_widget_size_allocate(window, &bounds);

Pretty sure this isn't allowed (and wasn't in 1.2 either);
size_allocate can only be called by the container containing a widget,
or by GTK itself in the case of a toplevel such as GtkWindow. It can't
be called outside of the size request/allocation process. (Where
containers recursively get child size requests, then recursively
allocate child sizes.)  Otherwise you'll confuse GTK.

For GtkWindow the "container" is conceptually the window manager, and
the size is allocated due to ConfigureNotify events coming back from
the WM.

Maybe gtk_window_resize() is what you want?

The following may not apply to you, but it's a guess based on how
every other wrapper toolkit we've helped people with tries to do this
initially. People try to use widget->allocation to store the wrapper
kit's synchronous concept of widget size. This is just "fighting the
system" and not a good idea. You need to keep GTK asynchronous as it
likes to be, and keep your own synchronous size information.

That is, say you have a Java notion of setSize(). You would implement
that by having a struct that is the "Java size" of the
window. Whenever the "Java size" of a window is updated you ask GTK to
change the size of the widget using gtk_window_resize(). When the
"Java size" is requested though, you return it from your own struct,
not from widget->allocation. That's because you want a
setSize()/getSize() sequence to work (return the size that was
set). But GTK doesn't work like that, gtk_window_resize() will only
really change the window's allocation if/when it gets back the
ConfigureNotify from the X server. So if you're using the allocation
to store the size you will not get the right semantics for toolkits
that make sizing look synchronous (and unmediated by the window
manager).

Havoc