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.
In this case, Aqua actually implements it's background as a border,
and by setting that border to null, we turn off both the text field
edge as well as the default white background. If someone just sets a
background color on our JTextFields, with simply do a fillRect() with
that color inside of the Aqua edges (and it looks terrible). Most of
the time, when folks are trying to create a multi-line label, they
null out the border too, so we catch those cases most of the time.
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.
Well, this all begs for a more powerful JLabel...but I digress.
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?
You might want to replace that component's peer with the
BasicTextPaneUI or another known UI delegate, since you are stripping
all the usual adornments off of it anyway. I fear that might reset
some things like ctrl-C vs. meta-C for copy (if you allow selection),
but all the other adornments like the Caret, or keybindings probably
aren't relevant, since this won't be editable.
Best of luck,
Mike Swingler
Java Runtime Engineer
Apple Inc.
