On 29 Nov 1998, Juergen Kreileder wrote:
> >>>>> Nelson Minar writes:
>
> >> If I use setSize(100,100); I get a frame that's smaller than that:
> >> something like 90x72 I think: I've deleted the source and can't be
> >> bothered retyping it.
>
> Nelson> Top level frame sizes unhelpfully include the size of the
> Nelson> window decorations - titlebar and borders.
>
> Right. If you use setSize(100,100) the frame should have exactly that
> size - including the borders and the titlebar. E.g. if the title
> bar height is 24 and border size is 4, the drawing area of the
> frame will have the size 92x72.
I think this is a terribly misguided implementation. On the X Window
System, there is no reliable way for an application to have any idea
of what the window manager is doing around the application's top level
frame, or even if there is a window manager at all. Comments in the
Sun souce code admit this. The code only claims to work properly for
the Motif/CDE window manager on Solaris, but I've been able to find
situations where it didn't work properly even on my Solaris machine
at work.
And what about window managers that might dynamically change the size
of their decorations (removing bottom and side frames and leaving
only a top bar, for example)? I don't think the Motif peer code
could cope with situation.
I'm porting the AWT peer code to GTK, and I've decided to cut through
this particular Gordian knot by defining a GTK FramePeer size to
not include any window manager borders, in line with most other X
applications. This has allowed me to junk hundreds of lines of code,
and has made the remaining code much easier to follow.
If you want your code to be portable, and to do what you expect on
all platforms, I would suggest never using Frame.setSize(); instead
you should set the sizes of the components inside the Frame and let
the Frame pack around them as necessary.
Nigel Gamble [EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/
