[cp-patches] RFC: Another try with GtkWindowPeer

[Roman Kennke]

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.

> 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?

While looking through the GtkWindowPeer stuff, I tried out fitzsims
suggestion to force-realize the window in create(). This turned out to
not work. Somehow no more mouse events get delivered. Anyway, I found
out that there is a realize-callback function that is called after the
window is realized. This callback-function does change the window size.
Now I have modified this to set the window size right. Please review
this patch and comment. At least this does fix the bug for me.

2005-04-21  Roman Kennke  <address@hidden>

        *  native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkWindowPeer.c
        (realize_cb): Resize window after realizing to take the
        window decoration insets into account.

/Roman

GtkWindowPeer.diff
Description: Text Data