Re: [cp-patches] RFC: GtkWindowPeer fix

[Thomas Fitzsimmons]

On Wed, 2005-04-20 at 22:06 +0200, Roman Kennke wrote:
> Hi,
> 
> I have found a nasty problem, that is visible when using the pack()
> method on frames. The problem is that before a window is opened, the
> insets of the window are (0,0,0,0) because the window decorations are
> not yet known about (I guess). However, after a window is up, the insets
> are correctly set to some sane value like (23, 5, 5, 5). The problem is
> that pack() sets the window size to the preferred size of the contained
> components and is usually called _before_ a window is opened. This
> messes up the layout and pack() has not the desired effect. I hope my
> explanations are not too confusing ;-) If you want to see what I mean,
> start the Swing example and open one of the dialogs by pushing the
> buttons. Do this before and after applying my patch.
> 
> The attached patch fixes this by resizing the window by the insets of
> the window decorations immediatly after the window is opened. Here this
> works pretty good, but since I'm not very familiar with the GTK code I
> think I ask better if I should commit this as it is, or if this can be
> made better.
> 

This results in a visible change in the size of the window when it's
first shown, which is messy.  Kim Ho and I looked at this problem
recently.  By using the _NET_FRAME_EXTENTS and
_NET_REQUEST_FRAME_EXTENTS window manager hints we should be able to
calculate the window's insets before it is packed.  However, the problem
is that the window must be realized before it can be queried using
_NET_REQUEST_FRAME_EXTENTS.

So that it is realized before pack does its layout, we'll likely need to
force-realize the window in GtkWindowPeer.create.  That may have side
effects though, I'm not sure.  Can you try that approach instead?

Tom