I believe I had filed a bug some time ago to clarify the spec of 'what
does background / foreground actually mean for Swing components'. I
ran into some issues with fixing bugs in the Windows Look and Feel. As
we started using more of the actual skins from the OS we no longer
used the background color set on a component, which was filed as a
regression against previous versions of the Windows Look and Feel.
This is one of those nasty 'what is the definition of correct' kind of
bugs. :)
-j
On Jan 22, 2009, at 11:01 AM, Omair Majid wrote:
Hi Mike,
Mike Swingler wrote:
On Jan 22, 2009, at 3:12 AM, Kirill Kirichenko wrote:
Hi Omar
Sorry for delay from out side.
I'm a responsible engineer for GTK L&F.
Omair Majid wrote:
I have noticed a few issues in the Gtk Look and Feel and would
like to know what the correct behaviour should be. The attached
program shows a few of my concerns.
1) For each of the components, setForeground(color) and/or
setBackground(color) assignments are randomly ignored. Is this
the expected behaviour? I can understand that using the native
look and feel, the feel is exactly preserved and the programmer's
preferences are ignored. But there doesn't seem to be any
consistency - some components accept the color changes, some
silently ignore it. Is there a list showing whether
setForeground() and setBackground() is ignored for each swing
component with the gtk look and feel?
Generally GTK L&F leverages theme settings for colors, indents and
fonts. And you shouldn't be able to change them using standard
swing API when GTK L&F is active. Sometimes this does work but you
shouldn't use this feature. This is the policy for GTK L&F.
Actually the have been similar requests and I tried to resolve the
issue. The thing is GTK itself doesn't allow changing colors
freely for all components it just uses the theme settings.
This is basically the policy of the Aqua Look and Feel on Mac OS X
as well. Sometimes we do pick up the foreground/background colors
for some controls where it makes sense, or the TCK requires us to,
but generally, we use our own system artwork to draw these controls.
Thanks for the insight!
Not every component (particularly non-rectangular ones) have a good
sense of what a "background" color is. Also, on Mac OS X, we are
particularly sensitive to allowing developers to create rainbow
kaleidoscope apps that clash with the rest of the Mac OS X desktop
experience, and try to make Java apps that have not necessarily
tested on our platform still look like Mac apps.
I agree, getting Java apps to blend in with the rest of the desktop
seems like the right thing to do. I just wasnt sure if that was
intentional or not in the gtk look and feel.
Cheers,
Omair
