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.