LookAndFeel-independent reference of color keys

Question

I am currently working on a set of custom controls for a product of the company I'm working in. For this, I am extending a lot of Swing controls and also overriding a lot of paint methods.

In order to maintain a consistent color scheme, I receive the colors for my paint, setBackground etc. methods using UIManager.getColor.

This was perfectly fine until we noticed that the Nimbus LookAndFeel, which is shipped with current JRE versions, uses totally different color keys, thus many things looks totally out of place.

For instance, while all other stock LookAndFeels (Metal, Windows Classic, Windows, CDE/Motif, GTK) have defined the key "text" as a bright background for texts and "textText" as the corresponding foreground color, "text" in Nimbus is actually a black foreground color, and a standard text background color does not seem to exist.

"TextField.background" would work, but that, for instance, doesn't exist for the Windows LookAndFeels.

I suppose you get the problem by now. I don't want to have to maintain a set of color keys for each LAF, who knows what LAFs will be added in the future and which my company may decide to use.

A simple solution would be getting rid of Nimbus, of course, but understandably my boss doesn't like this idea at all, besides Nimbus is part of the JRE these days and should be supported.

So I wonder whether there is any standardized way to get LAF-dependent colors like, say, "text background / foreground", "selected text bg/ fg", etc.?

Tortuous

Answer 1

There is no way around it - you have to create your own abstraction layer for color names (and possibly other property names).

Basically you have stock LookAndFeels (Metal, Windows Classic, Windows, CDE/Motif, GTK) that use their own color names and Nimbus that uses different names.

Create a class e.g. LafProperties so that for each property/color you have method (e.g. "getTextColor"). This class returns properties for classic Laf styles. Then extend this class for Nimbus, and change only methods that differ in Nimbus.

If stock Lafs and Nimbus have most of the properties differently named, than use you might use an interface and two implementing classes.

Ambie

Figured that this is the nicest way within the possibilities. I'm not liking it, but as you said, there is no way around it. – Tortuous

Answer 2

I'm not sure that there is a "standardized" way of getting these values.

As you noticed, Nimbus uses its own names for colors. Specifically, the properties textForeground and textBackground.

This oddness is likely because Nimbus uses a small selection of basic colors (listed as Primary in the chart), which have Secondary colors calculated from them, which in turn are used as the basis for all the remaining colors.

Trundle

Answer 3

Yea, as @josefx implied, unfortunately this isn't how the UIs work. They're not a pool of generic portable properties, rather they're a set of actual components and specific implementations for each of those components. It's not really an extensible system that's friendly to custom components.

The level of abstraction IS the component, not something finer grained. If you try to ask for a ComponentUI for a component that the L&F does not know about, you're out of luck. And the ComponentUI is little more than a wrapper for a paint method, so it's not obligated to expose any meta data at all.

Simply put, you're stuck basically doing the JTextField (or some other appropriate component) "color scrape" technique that josefx suggests, or adding specific support in your code to handle the eccentricities of the property names of the L&F's that you wish to support well.

Another suggestion is to "pre-empt" the L&F change, and subclass the L&Fs you wish to support to make your components more of a first class citizen within those L&Fs. When the L&F changes to a L&F that you support, silently switch out their class name with your subclasses class name, and then implement ComponentUIs for your custom components, and extend the parent LookAndFeel.createUI method so that it "knows" about your new components.

None of these are pretty, but the Swing component system isn't designed to be extensible at run time to handle custom components. The entire component suite is done all at once when the L&F is created.

Fleabag

Answer 4

Not a nice way but it should work for the basics:

1. Create a JTextField
2. call getForeground,getBackground,getSelectionColor to get the laf dependent values

Update:

The ComponentUI class and its subclasses which are the base classes for all look and feels only provide a method to initialise the laf dependent default values, they provide no direct way to access these values.

Arcboutant

Sorry for not replying for so long. As you said yourself, this is a pretty ugly method, but would work of course. I'm just not accepting that yet, hoping to receive some more ideas. – Tortuous

@Tortuous I would be happy to see a better solution myself. – Arcboutant

This also works only if the component gets visible it seems. Creating a visible control just to retrieve the colors from it is not good at all if you ask me, for various reasons. I prefer staying on the LAF level, which is why I accepted Peter Knego's answer instead. – Tortuous

Answer 5

The java.awt.SystemColor class provides variables for a lot of the common attributes.

For text foreground/background use the member fields text/textText; for selected text, use textHighlight/textHighlightText.

Basie

From what I've seen, however, it takes the colors from the system (as the name suggests), not from the currently active look and feel. – Tortuous

Answer 6

Few things ppop into my mind reading your question, which is a tad spiced with underbelly frustration if I have sensed well:

• dependancy on JRE standards/support versus independancy/freedom solutions
• standards & conformity versus creativity & customisation

And thus ultimately:

• practical approach of your boss versus programmers far future insights

Tercel

How is that an answer to the question? – Lenna