Frame shrinkage bug revisited
giles at nemeton.com.au
Thu Sep 3 14:08:42 PDT 1998
On Thu, 3 Sep 1998 13:09:25 +0200 "Peter C. Mehlitz" wrote:
> Some time ago, Marko Rauhamaa brought up a problem with Frame
> sizes. In order to mimic the JDK behavior (the spec doesn't define
> this), we treat Frame sizes like if they would include decorations
> (titlebar, borders) - which is of course just a lie if it comes to
This I think is related to the problems I saw and mentioned in a PR I
Subject: Minor FlowLayout fixes (nChildren -> getComponentCount(), ...)
I'm puzzled as to why my application code is fine under Sun's JDK if
they include decorations in the Frame size.
The bottom line for me is that application code that uses layout
managers and doesn't set sizes explicitly should do "The Right Thing"
on all platforms.
If applications that set sizes explicitly suffer some damage I'd not
be very concerned. I don't have a lot of code that does this,
possibly none. (So fix my code, and break the other guy's, yeah!)
P.S. A way to lookup PRs on the web would be good, as would emailed
acknowledgment with the PR number. The Description from my PR:
The current FlowLayout code lays out code incorrectly:
(i) in the presence of a Frame with a MenuBar the components
laid out by FlowLayout are under the MenuBar
(ii) components are horizontally shifted right
Problem (i) is fixed by using parent.insets.top appropriately.
Problem (ii) is improved (possibly fixed) by using the
getComponent() and getComponentCount() methods rather than
nChildren and the array children.
PROBLEM: after these fixes are made, the Frame size is not
correct. The calculation of the dimensions in FlowLayout
seems OK, and I think this bug was hidden by the previous
improper placement of components when parent.insets was
More information about the kaffe