We Keep Coding

what do these swing color names mean

Some of the names are clear, like background, foreground, focus etc. But some are just confusing, like light, hightlight, shadow, darkshardow etc. I noticed that these are consistently used in swing UI, so I infer these are part of java's jargon. Does any body know if there is a document out there that explains these names ?
RadioButton.background
RadioButton.darkShadow
RadioButton.disabledText
RadioButton.focus
RadioButton.foreground
RadioButton.highlight
RadioButton.light
RadioButton.select
RadioButton.shadow

These are UIResource elements related to JRadionButton. Each Look & Feel provides different radio button appearance, and may set different defaults for these elements. It is also to up to L&F implementation to use these keys or not.
For example, here is a method from javax.swing.plaf.basic.BasicBorders that uses RadioButton.light and RadioButton.highlight:
public static Border getRadioButtonBorder() {
UIDefaults table = UIManager.getLookAndFeelDefaults();
Border radioButtonBorder = new BorderUIResource.CompoundBorderUIResource(
new BasicBorders.RadioButtonBorder(
table.getColor("RadioButton.shadow"),
table.getColor("RadioButton.darkShadow"),
table.getColor("RadioButton.light"),
table.getColor("RadioButton.highlight")),
new MarginBorder());
return radioButtonBorder;
}
However, it is may not be used by concrete L&F implementations.
PS:
UIManager Defaults by #camickr can be handy to visualize different keys.

LookAndFeel-independent reference of color keys

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.?

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.

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.

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.

Not a nice way but it should work for the basics:
Create a JTextField
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.

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.

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

How can I get the text color of a button using the Substance LaF?

In my Java application I have to custom-paint a control and for that I need to use the same font colors as JButton. (Enabled and disabled) I don't want to hard-code them, because the user can change the Substance skin at runtime.
I'm aware of the ColorSchemes but I'm not sure how to proceed once I have the color scheme of the current skin. Also the Substance documentation says something about creating your own color scheme, but I just can't figure out the way to retrieve a certain color.

OK, finally I figured it out myself:
The important step is to figure out the correct color scheme. Because in Substance every root pane can have its own skin, it's best to use the getCurrentSkinhelper.
SubstanceColorScheme s = SubstanceLookAndFeel
.getCurrentSkin(myComponent)
.getEnabledColorScheme(
SubstanceLookAndFeel.getDecorationType(myComponent)
);
Other possibilities are getDisabledColorScheme, getActiveColorScheme and getBackgroundColorScheme.
Then you can use s.getForegroundColor or various helper methods from SubstanceColorUtilities.

Why don't you ask Kirill (creator of Substance) on Substance Forum at https://substance.dev.java.net/servlets/ProjectForumView

How do I prevent button surround from displaying in Java?

Sorry for the odd choice of words for the title, however, "border" seems to be the inappropriate term. While it is true that the visible line surrounding an icon in a JToggleButton can be made invisible by using setBorderPainted(false), the same is not true for JCheckBox and JRadioButton.
I can not use the JToggleButton and therefore need to use either the JCheckBox or JRadioButton (or some derivative of JToggleButton I am not aware of), but need the square or circle, respectively, to be non-visible when there is no icon on the button. Also, using setVisible(false) eliminates the button from the layout, however, I need the space to be reserved and not have the component layout change (using GroupLayout).
Any suggestions? Am I going to have to create a custom renderer? I will be looking at that in the mean time.

The route into this would be through customising the look at feel by changing some of the UI properties in the UImanager (the sort of thing that allows you to make simple tweaks with fonts and colours and presumably the images used for the checkboxes or radiobuttons) -- but it's many years since I last did that sort of thing and can't remember the details.
A little Googling turned up this project to inspect current property values, so might at least help with indicating the right part of the APIs to be looking at.

You have to choices here:
1) Customize Look and Feel as described in previous entry.
2) Create your own custom controls by inheriting from existing ones and overriding component painting.

I found a cheap and easy (read hack) for this. I created an empty transparent icon and used it when I didn't want any item to be displayed.

Java- Changing swing background colour?

Ok so ive got a swing app going using the "System" look and feel. Now, I want to change the background colour of the main panels to black. Too easy right?
UIManager.put("Panel.background", Color.BLACK);
Well yeah, except now the controls in the app look stupid, because their 'shadows', for want of a better word, are graduated to fade towards the old system default colour(gross windows grey). So there are light grey 'corners' on all the controls, especially the tabs on JTabbedPane.
I know it can be fixed, because if you change the windowsXP theme to one with a different default application colour, the controls take on this changed colour and their shadows 'fade' towards it.
But I have no idea what UIManager key it is, or even if you can do it with UIManger.
I dont really want to change the L&F engine, because apart from this it looks good.

You might try these:
control
controlDkShadow
controlHighlight
controlLtHighlight
controlShadow
(I just found them in this list: Swing [Archive] - UIManager: setting background and JScrollBar )

In general this is a little bit tricky. It depends on exact LaF you are using.
For example. JGoodies use own color scheme which redefine this stuff.
In general the property names are composed like
COMPONENT_NAME_WITHOUT_J + '.' + PROPERTY.
Unfortunately, property names can be only obtained from implementation classes of LaF. These aren't shared or something. Each component has its own. Or better, it depends on laziness of author which pairs he used. In general.
A lot of help makes redefine Panel.* and Button.. A lot of components use Button. properties.
Try, play, win :). I wish you luck :).
PS: It is a lot of properties to overwrite. But this is the way how LaFs works.

You can see what the default settings (and their keys) are by using UIManager.getDefaults();
You can then iterate over the resulting keySet (it is an instance of Map).
So something like this will show all the default keys:
for (Object key: UIManager.getDefaults().keySet())
{
System.out.println(key);
}

Some controls like JButton need to have setOpaque(false) called to allow the new background colors to fade through.

To list out all the possible options that we can set to UIManager to change LaF, run the code below ........
import java.util.*;
import javax.swing.UIManager;
public class UIManager_All_Put_Options
{
public static void main (String[] args)
{
Hashtable properties = UIManager.getDefaults();
Enumeration keys = properties.keys();
while (keys.hasMoreElements()) {
String key = (String) keys.nextElement();
Object value = properties.get (key);
System.out.printf("%-40s \t %-200s \n", key,value);
}
}
}
enjoy...