classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] RFC: GtkWindowPeer fix


From: Roman Kennke
Subject: Re: [cp-patches] RFC: GtkWindowPeer fix
Date: Wed, 20 Apr 2005 23:32:47 +0200

Am Mittwoch, den 20.04.2005, 17:04 -0400 schrieb 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.

Yeah I noticed this too.

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

I'll try that. It is a bit of unchartered territory for me, but that
makes it only more interesting.

/Roman






reply via email to

[Prev in Thread] Current Thread [Next in Thread]