Frame shrinkage bug revisited

[Giles Lean]

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
> X.

This I think is related to the problems I saw and mentioned in a PR I
filed on:

    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!)

Regards,

Giles

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
	ignored.