I am curious about a design decision that was made in the implementation of textured window backgrounds in the Aqua LAF/AWT.
In a nutshell, a textured window background is an optional NSWindow background style that involves gradients. Textured windows are requested in Java using a window client property. The implementation of this property sets the appropriate style on the NSWindow. More importantly, it also attempts to prevent Java from painting over the window background in places where the textured background is intended to be visible. Part of this is preventing Java from painting its own window background. The more interesting part is preventing certain components from painting over the textured background. This latter issue is handled in an unusual way. That Aqua LAF changes the behavior of JPanel, JRootPane, and JToolBar when painting the component background. If the component background color is a UIDefault that matches the system window background color, then instead of painting the background, it erases the corresponding region in the layer (frame buffer). The effect is to punch a hole in whatever background was painted by ancestor components. I am wondering why a more straightforward solution was not chosen -- making isOpaque()==false and background==Color(0,0,0,0) the default for all components that normally reveal the window background. (I tried this and it seems to work. I see various comments in the code that there must be an opaque component at the top of the hierarchy, but I have not found that to be true on OS X.) Is this a performance issue? A compatibility issue? An architectural issue? The components that would need to change are JPanel, JRootPane, JLayeredPane, JOptionPane, JSplitPane, JToolBar. Thanks in advance. Alan
