It seems my last patch for JRootPane was wrong. I revert it, though it
causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27481 to be reopened.
2006-05-10 Roman Kennke [EMAIL PROTECTED]
* javax/swing/JRootPane.java
(createContentPane): Don't set background to null.
/Roman
The content pane in a JRootPane must have its background color set to
null, so that it inherits the background from the surround containers
(whichever is the first to have a non-null background, usually the
JFrame or JInternalFrame containing the JRootPane).
2006-05-08 Roman Kennke [EMAIL
On Mon, 2006-05-08 at 16:22 +0200, Roman Kennke wrote:
The content pane in a JRootPane must have its background color set to
null, so that it inherits the background from the surround containers
(whichever is the first to have a non-null background, usually the
JFrame or JInternalFrame
The attached patch makes painting in Swing a little more correct by
letting the JRootPane override isOptimizedDrawingEnabled. This is now
implemented to return true only when the glassPane is invisible.
Otherwise, the glassPane overlays the rest of the JRootPane and must
always be considered when
The JRootPane in Sun's implementation is opaque, so should we do. This
allows for some nice painting optimization (if the root pane isn't
opaque, the painting goes up to the toplevel container, thus jumping out
of Swing and going through the inefficient AWT painting.).
2006-02-13 Roman Kennke
I found this while running some tests for a JInternalFrame bug I'm
working on. JRootPane's setContentPane method should remove the old
contentPane before adding the new one. Also, the API says it should
throw an IllegalComponentStateException if the parameter is null. Fixed
these. Attached.
The attached patch makes JRootPane align the menubar to the left instead
of taking the whole width. Looks much better now.
Again there are various tab vs. space fixes. Please forgive my batch
commit :-/
2005-04-12 Roman Kennke [EMAIL PROTECTED]
* javax/swing/JRootPane.java:
