Created attachment 82350 [details]
screen shot

There is, of course, no special code related to background of forms and background of main window. The form simply 
follows customs of AquaLookAndFeel. Why do you think that the GUI builder is doing something odd? Is there any 
difference against other Java applications executed in this environment?

I expect that a form that is being edited should look like a form that is alive.

I'm guessing that the window system is setting the background color of the root pane or main window itself, or changing
UIManager colors or something like that to achieve the color change when the window is deactivated.  Which is fine for
the IDE, but it makes forms look very strange - and hard to read when you are editing them.  So the form editor probably
needs to work around whatever was done to the window system somehow.  Apple's interface builder does not show you
black-text on dark-gray in its designer;  neither should ours - it's hard to read and doesn't look like what the running
app will do.

The point being, if I create a new JFrame on Mac OS with a new JPanel in it and some contents, it does not look like
what I see in the form editor.  So what we are doing to give the *IDE* fidelity to native mac apps is having a bad side
effect in the form editor.  Just find out what whoever made the winsys mods for mac os did, and there's probably a
simple way to work around it like making some parent component opaque.

This is currently the personal show-stopping block for using 6.7 permanently on OSX, in my testing. It shows the wrong color even when background is 
overrided to specifically display the default expected color [238,238,238], instead showing what appears to be [153,153,153]. Interestingly, when the 
Properties window is open, it seems to display the correct color, but as soon as I close the window, it reverts to the incorrect color. The correct color is also 
used when the program itself is launched, and the preview shown in the GUI builder should reflect that.

I wrote a similar patch I still have in a pile of uncommitted mac-os fidelity patches.  The code was dead-simple - add a
WindowListener to the main window and call setBackground() with a different color on activated/deactivated.  

Probably the form in the designer is either so transparent that the window background shows through, or is inheriting it
somehow.  This should be a 2-line fix.

Raising to P2 because it presents a serious usability issue with the form editor (it is hard to even read labels on a
form unless you de-focus the IDE window), and it should be quite simple to fix.

Maybe designed form inherits the window background of NetBeans which might be incorrect. In such case we'd need to set 
a specific color. Any advice what it should be? I.e. what color from UIManager.

UIManager.getColor("control") seems reasonable

The described problem is caused by the fact that the rootPane of the main NetBeans window 
has "apple.awt.brushMetalLook" client property set to true. See 
http://developer.apple.com/technotes/tn2007/tn2196.html#APPLE_AWT_BRUSHMETALLOOK

e.g. the GUI builder follows customs of AquaLookAndFeel with this property set to true. Unfortunately, the default 
value of this property is false. That's why the executed forms don't behave that way. It would be nice to implement 
some hack/workaround that would allow the GUI builder to behave as if this property was set to false, but this is not 
possible. The color changes (performed when this property is set) are not implemeted using standard Java means e.g. no 
setBackground() call is performed on the affected components. The change in painting is performed by some native code. 
We also cannot change this property to false temporarily (for example, during form painting) because changes to this 
property don't have any effect once the (main) window obtains its peer.

Happily, there is a workaround that you can use. You can start the IDE with "apple.awt.brushMetalLook" system property 
set to anything non-null (this will set the mentioned property to false). For example, you can start the IDE using the 
following command line

./netbeans -J-Dapple.awt.brushMetalLook=false

Okay, I didn't know the brushed metal look was now enabled - that explains a few things.

But good heavens!  There is a two-method fix for the form editor:

public boolean isOpaque() {
    return true;
}

public void update(Graphics g) {
    Color c = UIManager.getColor("control");
    g.setColor(c);
    g.fillRect (0, 0, getWidth(), getHeight());
    paint (g);
}

We're not talking about something that takes a lot to fix here.  Right now, the form editor on Mac OS
1.  Doesn't look like what your app will really look like
2.  Forces people to try to read black-on-dark-gray text

Please, do not reopen this issue just because you have some unverified idea how to fix it. Your evaluation is incorrect 
from the start - the problem has nothing to do with opacity and with main window background changes. The 
apple.awt.brushMetalLook property directly affects painting of many component types in the whole window (JPanel, 
JTabbedPane, JSplitPane etc.) and it doesn't do that through standard Java means.

If you really believe that the fix is simple then please provide complete GUI builder patch. I will integrate it 
gratefully. I am sure that I spent much more time with this issue then you and I don't see any clean way how to 
fix/workaround it.

I will try to provide a patch.

It may be that the bug is that we should not be using brush metal look for NetBeans - doing that violates Apple's UI guidelines (I turned it on for 1 week in 
2003 in builds and we turned it off for that reason - it has the one use here that it makes the toolbars look good - but there are other ways to do that and I 
have already written patches to solve it).

But are you really telling me that overriding paint() or update() on a component sometimes is ignored by Apple's look and feel?  It is hard to believe that or 
there would be very big problems with any custom component in any Java app.

I am sorry if you wasted some time on it - but since you did, if you tell me what you tried, we can work together better to both find some optimal fix (I 
think the fix may be to reopen the P1 bug that made me turn off brush metal look on Mac in January 2003 - but it does look good, so we should probably 
try to find some nicer way to solve it before we bring out the sledgehammer).

> It may be that the bug is that we should not be using brush metal look for NetBeans 

Yes, that also can be a solution of this issue, but I don't feel competent to decide
this. It should be consulted at least with S. Aubrecht (who, I believe, is responsible
for re-introduction of this switch).

> But are you really telling me that overriding paint() or update() on a component
> sometimes is ignored by Apple's look and feel?  It is hard to believe that or 
> there would be very big problems with any custom component in any Java app.

No, I am not telling that. We can override paint() or update() in components
that implement the GUI builder itself e.g. in the top-level container of
the GUI builder, but we cannot affect components used to implement the form itself
(e.g. all the JPanels, JTabbedPanes etc. used by the user to implement his/her UI).

By "non-standard Java means" I meant that the change of the color of several components
is not caused by change in UIDefaults or by invocation of setBackground() method. The components
still have the same value of background property, but the Apple JDK is performing a different
painting (on some low level - probably even in a native code) when the main window is focused or not.

*** Bug 182217 has been marked as a duplicate of this bug. ***

*** Bug 182217 has been marked as a duplicate of this bug. ***