3.8 toplevel resize bug?

[Roger Davis <rbd soest hawaii edu>]

Hi all,

I have some questions about gtk+ window manager interaction relating to
what appears to me to be a bug in the latest 3.8 release. The reference
manual for 3.8, under the description of the gtk_window_set_default_size()
routine, states that

   The default size of a window only affects the first time a window is
   shown; if a window is hidden and re-shown, it will remember the size
   it had prior to hiding, rather than using the default size. 

The latter half of the above sentence no longer appears to hold true for
many of my apps after switching from 3.6.2 to 3.8 -- when I do a
gtk_widget_hide() on a toplevel window and subsequently do a
gtk_widget_show(), the window does not reappear at the same size it had
just before it was hidden. Instead, it reappears at a postage-stamp size
that is just large enough to display the window manager control buttons in
the titlebar added by the window manager. I am quite certain that I am
doing nothing to these windows myself between the hide and show calls.
Under 3.6.2, all of my apps perfectly conformed to the behavior described
by the documentation, and they are now universally broken in this regard.
This is happening under CentOS 6.4, with all gtk-related packages except
pango (still at 1.32.4 due to the configure problems mentioned elsewhere
on this list) upgraded to current revisions.

This may have something to do with the particular nature of my toplevel
windows, as I can't believe that general behavior like this would have gone
unnoticed in the 3.8 release development process. My typical toplevel window
contains a GtkScrolledWindow (using GTK_POLICY_AUTOMATIC) as its only direct
child, which in turn contains a GtkLayout as its only direct child. The
latter will contain many different children of various types depending upon
its purpose. Before I first map the toplevel, I calculate the minimum size
(w, h) needed to show everything contained within the GtkLayout, and that
size is used as follows:

        gtk_window_set_default_size(GTK_WINDOW(toplevel), w, h);
        gtk_layout_set_size(GTK_LAYOUT(layout), w, h);
        geom.max_width= w;
        geom.max_height= h;
        gtk_window_set_geometry_hints(GTK_WINDOW(toplevel), NULL, &geom, GDK_HINT_MAX_SIZE);

When the toplevel is initially mapped with gtk_widget_show() it appears
at the correct size, with no scrollbars visible. The user cannot enlarge the
window because of the GDK_HINT_MAX_SIZE setting, but can make it smaller, in
which case the scrollbars appear. All of this still happens properly in 3.8.
My problem is that when the window is hidden and reshown, under 3.8 it now
does not reappear at the same size it was before unmapping, but rather at
the ridiculously small size noted above (although the user can still enlarge
it up to GDK_HINT_MAX_SIZE).

So, my questions are as follows:

(1) Is it still policy that any toplevel window which is hidden and reshown
should reappear at its last visible size if the application does nothing
between the hide and show to alter its size? The manual still says so,
and I should think that from the user standpoint this would still be
the expected reasonable behavior.

(2) If the answer to #1 is yes, then does anyone see anything in the
foregoing description of my toplevel window details that would contribute
to breaking that policy?

I have tested a workaround that seems good so far (maintaining my own memory
of window sizes through configure event handling, then manually resizing the
windows to those sizes just before remapping), but it seems awfully kludgy
and a lot of work as I have lots of windows in my apps to patch up. If this
is truly a 3.8 bug, I would greatly prefer to just see that bug get fixed!
I can work up sample demo code as necessary to demonstrate this behavior,
but before I do so I just wanted to see if anyone had any observations on
the above.

Thanks!

Roger Davis