If we wish to support custom components that try to fit in with the native look and feels (which I think is your goal, right? To use a textpane for a fancy label?), then the look and feel should pre- populate the defaults table with the right colors. Then other 3rd party code and query that table when trying to do the right thing. This still means that the native L&F can ignore setBackground, but at least you'll be able to make your own code respect colors properly.

- Josh

On Jan 22, 2009, at 1:21 PM, Joel Uckelman wrote:

Hi,

I'm the guy who reported the bug which Omair was referring to. The context in which in which I noticed that the GTK L&F ignores setBackground() is that I was subclassing JTextPane in order to get a label which would support both word wrap and full justification of text. In this case, the correct background color is really not what the theme thinks the background color should be for a JTextPane, but rather what the theme thinks the background
color should be for a JLabel.

This kind of policy makes the uses to which components can be put very narrow if you're using a native L&F. To be clear: What I want to achieve is to have this component of mine to have the same background color as a JLabel, because it *is* functionally a JLabel, despite that it inherits from JTextPane. I'm not trying to circumvent the color scheme provided by the L&F here, I'm trying to follow it---so it's very disheartening to read the replies on this thread.

If the intended behavior of native L&Fs is to ignore setBackground(), then
what's the right way to do what I'm trying to do?

--
J.

Reply via email to