Posted on Aug 27, 2008

Nimbus UIManager UIDefaults

Nimbus is completely configured by properties in the UIManager defaults table. In my last blog I showed a simple example of how to skin a single component. This gave you a sneak peek into the power of these properties. Lots of people have asked for a complete list of properties that can be set, well its simple just grab UIManager.getLookAndFeelDefaults() and iterate over the contents of the map and print the keys and values and there you go. Well I am not that cruel so I did the work for you and will include a link to a complete table of them at the end. But before I get to that let me explain how they work.

Nimbus properties follow some rules and you can not only use the property keys that we have added in as default but you can create your own. Nimbus Look and Feel scans the UIDefaults table when ever you add a property with UIManager.put(<<key>>,<<value>>) then updates its internal state. When that new property matches the current state of the component it applies to then it will be applied to that component. Properties cascade like CSS and the most specific matching one is used.
Example:

  • foreground = Color.BLACK
  • Label.foreground = Color.BLUE
  • Label[Disabled].foreground = Color.GRAY
  • "SomeLabel"[Disabled].foreground = Color.WHITE

In these examples foreground applies to the foreground of all regions of all components, Label.foreground applies to only Label components, Label[Disabled].foreground applies to only Label components in the Disabled state. "SomeLabel"[Disabled].foreground applies to all components named “SomeLabel” that are in the disabled state. Hopefully that also explains the different ways you can write a rule to match a Component. The only 2 cases that are not covered here are Component.Region.foreground which lets you specify a sub-region of a component and ComponentA:ChildComponentB.foreground which lets you specify a ChildComponentB contained within ComponentA. You can see many examples of these in the complete table below and then play with writing your own. For example you can use the “name” property of a component in a similar way to “class” in CSS, say naming a bunch of buttons “hotButton” and then specifying new rules for them in the defaults table. I already explained in my last blog how you can override the global defaults on a single instance bases which matches the “style” attribute with HTML CSS.

Colors in Nimbus are derived, which means there are a core set of colors which are constants and all the other colors are calculated from those. This means you can simply change those and the 1000s of other colors that are related and used in the painters will update to reflect the new base color. These colors are shown in the “Primary Colors” section of the table. The colors in the “Secondary Colors” section are derived from those in the “Primary Colors” section but themselves are used as the base colors for other colors. You may need to change the secondary colors to tweak the results of changing the primary ones if you are not happy with the results. You can you derived colors in your own code as well so that you colors can change when the primary colors change. This will allow you to make your application color theme-able idea for white label branding etc. The method you need is on NimbusLookAndFeel called getDerivedColor :

/**
 * Get a derived color, derived colors are shared instances and is color
 * value will change when its parent UIDefault color changes.
 *
 * @param uiDefaultParentName The parent UIDefault key
 * @param hOffset             The hue offset
 * @param sOffset             The saturation offset
 * @param bOffset             The brightness offset
 * @param aOffset             The alpha offset
 * @param uiResource          True if the derived color should be 
 *                            UIResource, false if it should not be
 * @return The stored derived color
 */
public Color getDerivedColor(String uiDefaultParentName,
               float hOffset, float sOffset, float bOffset, int aOffset,
               boolean uiResource)

Hopefully the rest will make sense as you read though the table and look at all the examples. After that its just a matter of try playing with some and see what you can do. I hope you see that power in this that Richard Bair and I designed and hoped would be useful. The complete defaults properties table is way to big to include in this post so I have put it on a separate page.

If you would like to see how I made this list, here is the code that creates the html.

Java Icon
NimbusBrowser.java

92 Comments

  • Paul Blessing says:

    From my observations, the Nimbus indeterminate progress bar seems to flip between the two different animations depending on whether the progress value is at 100% or not. I’d vote for the tiled-looking one to be the default as well – the normal one is indeed rather strange looking.

    • Jasper Potts says:

      Paul: Ok that might make sense, how random. The default look is what was designed by the designer for the Nimbus, Nimbus is not only a Java LAF it is also a GTK theme on Solaris and a Web theme for other Sun products. So the Java version needs to match the others so I could not freely change the look of things.

  • Hi Jasper. Nimbus is incredibly flexible. Thanks for your work. I did want to add my voice to those who have already asked how to get named components to accept styles added to the UIDefaults. Your example above with a component named “SomeLabel” doesn’t seem to work. Is this feature unavailable in the current version of Nimbus?

  • Endre Stolsvik says:

    Compared to the BasicLookAndFeel, which I thought you’d inherit through Synth, you change the parameter names for already established parameters, as well as how parameters are read.

    I refer to e.g. the BasicTabbedPaneUI.installDefaults(), where a bunch of parameters are read, e.g. “TabbedPane.tabAreaInsets”.

    This parameter you have seemingly changed to “TabbedPane:TabbedPaneTabArea.contentMargins”.

    Although I get the rationale – to get a consistent and meaningful hierarchy of names – this does however make for a break in the ability to LaF-independently change aspects of the currently installed LaF.

    For most other existing LaFs, one can for example change this particular inset by using that particular Basic-defined UIDefaults parameter, and thereby make room for “leading” and “trailing” components before and behind the tabs (the “stick-uppers”) themselves (e.g. a “close” button, or a “new tab” button, or for my case, the minimize, maximize and close frame buttons).
    This at least works for Windows (both Sun and JGoodies extended), Motif, Metal and the third party Substance.
    However, when setting the LaF to NimbusLookAndFeel, this particular property doesn’t work anymore, and must be replaced with the above mentioned Nimbus specifics.

    Furthermore 1: Contrary to the article, I find that Nimbus only reacts to settings on the form UIManager.getLookAndFeelDefaults().put(..), not UIManger.put(..) (as the article states), nor UIManager.getDefaults().put(..). This is contrary to the other themes, where the “user-modifiable” defaults-table (IIUC) getDefaults() are indeed reacted to.

    Furthermore 2: Contrary to all the other themes, it does not seem possible to change a value after the affected value is first read: After e.g. a JTabbedPane is instantiated, it is no longer possible to change that LaFDefaults value – such changes are ignored. This means that the following particular hack cannot be employed for Nimbus: set one UIDefaults value, then instantiate “the special” component. Then set the default/standard UIDefaults value, and instantiate the rest. Since all the other themes read properties upon instantiation (in the installDefaults() method), the special component will end up with the special value compared to the others. On Nimbus, all components gets the last value that is set before the first component is created. (Granted, on LaF (re)sets, this fails, and the special will also get the latter value. But it /is still possible/ to overcome that problem too using more hacks (!): Install a pro-listeners that enables a sort of “around advice” on the installDefaults method, and you can keep the hack up)

    GRANTED, you mention that you have a very nice fix for this overall issue, which should have been in ALL themes: the name-based “CSS”-style cascading styling (as well as the component-specific client properties UIDefaults-setting). This indeed seems lovely. However, since the older/other themes doesn’t have this, while Nimbus doesn’t cover the old way of doing things – one does end up in an awkward situation.

    I therefore suggest a three-fold modification to Nimbus: That you fix the “Furthermore 1″ (Nimbus should properly react to properties set by the user, as in UIManger[.getDefaults()].put(…), not only on the LaF UIManager.getLookAndFeelDefaults().put(…)).
    Change the way it re-reads all properties, that is, the “Furthermore 2″ (read the value upon instantiation – if you want to change stuff “mid flight”, you’ll have to re-set the LaF to have the new values honored).
    Finally, which really was the initial intention behind this email, I suggest that you also check the proprietary, “de-facto standards” BasicLookAndFeel UIDefaults properties, in addition to your new stuff. The new stuff overrides – but if there is nothing there, check back to the old parameters.

    I guess this seriously is a long-shot, but I just wanted to chip in these observations. I’ve found the LaF field to be VERY confusing, and sadly I feel that Nimbus actually added somewhat to this.

    However, it also leads the way for a much better future, regarding the cascading and “component named” styles.

  • Jose says:

    I have a doubt regarding to changing the L&F in runtime.
    When doing this, the memory grows every time I changed the theme. Is it a bug? Is it a memory leak?
    I was told that a restart of the application is needed after changing the L&F. Is it right? Thank you in advnace!

    • Jasper Potts says:

      Jose: I would not be completely suppressed to find there is a memory leek in changing from Nimbus to other LAF. There is a lot of cleaning up to do as a lot of intelligent caching is going on. It is not a often used feature other than in demos and testing in real apps people would switch at most 1 or 2 times so unlikely to get noticed. File a bug if its a issue for you.

  • CW West says:

    It would be wonderful if there was a collection of quality color schemes for Nimbus somewhere. Doing colors right is very hard work!

  • Scott says:

    I am trying to set the background color of a panel that contains a toolbar. I have named the panel and tool bar and tried to access the components that way with out luck. I have read all of your documentation and I believe I am doing this correctly but nothing is working.

    //Setting layout of panel and adding toolbar to the panel
    saveCancelPanel.setName(“toolbar”);
    saveCancelPanel.setLayout(new BorderLayout());
    saveCancelPanel.add(toolbar, BorderLayout.CENTER);
    UIManager.put(“\”toolbar\”[Enabled].background”, new Color(1,188,127));
    UIManager.put(“\”toolbar\”.background”, new Color(1,188,127));
    UIManager.put(“\”toolbar\””, new Color(1,188,127));
    UIManager.put(“ToolBar.background”, new Color(1,188,127));
    UIManager.put(“ToolBar[Enabled].background”, new Color(1,188,127));

    • Jasper Potts says:

      At a quick glance it looks correct what you are doing, I have known there to be bugs with named components so you might have hit them. Try doing a updateUI() on the components that it should be matching so that they refresh their styling that might help. You can use SwingUtils to do a updateUI to a whole component tree if that helps. If that doesn’t work then please file a bug with a simple test case. Thanks Jasper

  • Presence Of Mind says:

    Hi All,

    I’ve started using Nimbus a week ago. I’m impressed with this L&F. Is quite different with all the other available and sure is a good choice to go.

    But unfortunately I’m having some compatibility issues migrating my components to this layout. Looks like some generic features available on other L&F are missing. Therefore some of my controls are going nuts.

    Is there a support group? Who should I talk to this through?

    Thank you

  • m says:

    For all JButtons, I would like to change the font and apply a gradient background, so I think I must do the following:

    NimbusLookAndFeel laf = new NimbusLookAndFeel();
    laf.getDefaults().put(“Button.font”, new Font(“Tahoma”, Font.BOLD, 14));
    laf.getDefaults().put(“Button.buttonBackgroundPainter”, new CustomPainter());
    UIManager.setLookAndFeel(laf);

    The button font is set correctly, however, the CustomPainter.paint() is never called.

    Does anyone know what I am doing wrong? or how I can invoke a custom painter for the button background?

    Thanx!

  • m says:

    Oh duh. Guess I sat at my desk too long w/out a break. Thanx for the quick turnaround! m

  • m says:

    Okay, my background painters are working now…. but my foreground text is misbehaving. I set the following:

    laf.getDefaults().put(“Button[Default+Pressed].textForeground”, Color.BLACK);
    laf.getDefaults().put(“Button.textForeground”, Color.WHITE);
    laf.getDefaults().put(“Button.disabledText”, Color.DARK_GRAY);

    yet the result is:

    Disabled JButton – foreground text is Color.WHITE
    Enable unpressed JButton – foreground text is Color.WHITE
    Enabled pressed JButton – foreground text is Color.WHITE

    Am I overlooking something again?

    Thanx, m

  • Andrew Barnham says:

    Hi

    I am trying to customize contentMargins for certain buttons (not all them – otherwise buttons in forms like file dialog are affected too).

    The notion of using setName() doesn’t appear to work. i.e. :
    defaults.put(“Button:clarion.contentMargins”,new Insets(6,0,6,0));
    defaults.put(“Button:\”clarion\”.contentMargins”,new Insets(6,0,6,0));

    I found a workaround – which was to use Nimbus.Overrides client property. It worked fine until I tested it on a later version of JRE – each time i instantiate the swing component – Nimbus leaks vast amounts of memory. On a low spec machine – after user bounces in and out of about 100 windows or so (20 minutes of typical usage) – application becomes unusable. I have not pinpointed root cause – but leaky objects are all around recently added ColorTree etc. so probably started happening at u14. u10 is fine. u17 & u18 are definitely broken. Have lots of jmap histogram outputs, test code, line plots etc demonstrating this (posted on SDN – awaiting reply).

    Working on a slightly unusual project whereby normal layout managers cannot be applied – and additionally I need to be able to override behaviours like contentMargin settings.

    Cheers
    Andrew

    • Jasper Potts says:

      Looks like a nasty bug with the memory leek in ColorTree. That was not something I wrote, if you send me a bug id for the issue you filled I will try to get it looked at. I can’t remember the exact named component syntax at the moment and don’t have time to look it up. All the source for Nimbus was released into Open JDK 7 so you can grab the source there and follow though and see exactly what is supported. Sorry for making you do the leg work on this one I am just working on another deadline. Jasper

  • Andrew Barnham says:

    Thanks – greatly appreciated. This is what I have back from Sun so far.
    —-
    Your report has been assigned an internal review ID of 1699855, which is NOT visible on the Sun Developer Network (SDN)
    —-

    Let me know if you need more.

  • Andrew Barnham says:

    I had a brief look at Nimbus code from openjdk. My initial reading of it is that there is no ready way to set contentMargins based on component name and that contentMargin is a special case property. contentMargin is fixed per NimbusStyle instantiation. Maybe there is some trick I can figure out a way to instantiate a single NimbusStyle that services every instantiation of my custom “clarion” jbutton class (Nimbus.Overrides seems to instantiate a new NimbusStyle for every component which is probably at the heart of the colortree memory leak). I am also a bit pressed for time right now – but if things free up in a week or 3, then I’ll take a closer look and try to discover a good efficient workaround or patch. In meantime my workaround is – don’t use JRE u14 or above!

  • osc says:

    Have you noticed that TitledBorder draws the background color of the title over the shaded outline when TitledBorder.TOP is used? Any chance you might make the background transparent so that the outline could come through?

  • Tony Lindsay says:

    I think Nimbus is an excellent look and feel. Overall I have been very happy with it…
    However I am having one issue where I’m having trouble finding a solution.

    When the focus is given to an input component (such as JTextField, JSpinner etc) a 2 pixel border is painted around the component. In most cases this is desirable as it provides a nice visual cue to the user. However, when displaying an inline editor on a JTable, this focus highlight causes the input component to be smaller. The effect is a ‘squished’ input field. To compensate, I have increased the row height of the table but this causes the table to occupy much more space.

    Is there a way to selectively remove the focus highlight for an input component? If not, maybe this could be added in a future release?

    • Jasper Potts says:

      You should be able to change it simply. Just need to turn off paint for background of the text field being used as a editor and maybe reducing its padding. Basically need to set 2 properties in the client properties as shown in the blogs here. Should work. Sorry don’t have time at the moment to work out exact lines of code you need.

  • Chris says:

    Hello,

    I’m having a problem similar to Kevin’s from above. I have noticed some strange behavior with MenuBar colors. I would like to have a different color for selected text.

    theDefaults.put(“MenuBar:Menu[Enabled].textForeground”, Color.WHITE);
    theDefaults.put(“MenuBar:Menu[Selected].textForeground”, Color.BLACK); // Doesn’t work!

    It seems that if I specify the Enabled color, Nimbus will always use it. It will only use the Selected color if I don’t specify an Enabled color. I have tried using “Enabled+Selected”, but that doesn’t work either.

    Any ideas on how to work around this?

    Thanks.

  • Erik L says:

    Has anyone figured out how to change the Fonts? I am developing on Mac java 1.6_0_17. I have tried setting the fonts for JLabel and it does nothing. I tried setting defaultfont before setting the look and feel to Nimbus and this only changed the font for one tab title.

  • Werner says:

    I’m just trying to change color backgrounds from Radiobuttons, Tableheaders, Menubars, and the background from a Jtable thats currently don’t include any data’s. All this components are in a Swing Application involved. I have tried it with the follow code:

    UIManager.put(“RadioButton.background”, new Color(0,0,0));
    UIManager.put(“MenuBar.Enabled.background”, new Color(0,0,0));
    UIManager.put(“TableHeader.renderer[Enabled].background”, new Color(10,10,10));

    But it doesen’t work. It woult be very glad If you would help me in this matter. Thank’s in advance

    Werner Hasselberg writing from Germany

  • peter says:

    I am trying to change TableHeader.background but no chance anyone find solution with Nimbus?

  • [...] reading Jasper Potts blog entry about Nimbus look & feel customization I started writing some code to see how powerful it was. I focused my tries on this part of the [...]

  • Paulo says:

    Hi Jasper,

    Congratullations, you did a great job on Nimbus.

    I have some doubts, probably because i don’t have much experience on working with lafs.

    I have a special requirement on a JTable header, so i had to create my own JTableHeader implementation using a customized TableHeaderUI (that extends BasicTableHeaderUI). I’ve followed some basic steps like providing implementations for the createUI and installUI methods on TableHeaderUI among others. But it doesn’t work.

    How can i do that? What are the steps i should take when implementing a DelegateUI? Should i use the painters in paint method? Should i paint the background and borders on update method? Is there an example of how i could use that?

    If you want me to send you the classes so that you can check exactly what i’m doing, please tell me.

    Thanks a lot for the help,
    Paulo R.

  • Martin Schüler says:

    Hello everyone,

    I’m trying to write own UI-Delegates for Nimbus LaF. It’s important to add more than one for the UI-Delegate.
    That’s not a problem for components like Button or Togglebutton especially Components without subregions.
    I have a problem with UI-Delegates with subregions like tabbedpane or slider.
    Can anybody show me, how to add custom sliders / tabbedpane to Nimbus Look and Feel and prepare the UI-Delegates ??
    Can everyone help me??

  • Rob Philipp says:

    Nimbus is really awesome.

    I have one problem though that I can’t seem to solve. I would like to have borders around my JTabbedPane and I just can’t figure out how to add them.

    Does anyone know how?

  • Josh says:

    Hi Jasper,

    Great job with Nimbus :)

    I was wondering, the disabled ToolTip Background is a little hard to read, so wanted to change it, but only found ToolTip[Enabled].background … I tried ToolTip[Disabled].background but with no avail. I tried using RGB color and HEX.

    I guess this isn’t a key yet?

    Cheers,
    Josh

  • Philipp says:

    Hi,

    I like Nimbus, but there are a few things that are VERY frustrating (after playing around a while):

    In http://download.oracle.com/javase/tutorial/uiswing/lookandfeel/_nimbusDefaults.html#primary there are lots of items and colors, all seems very well-thought and easy to use. Sadly, it turns out to be quite messy:
    1.) Nimbus seems to ignore most of the items in the list, mainly those that dont start with nimbus – so why are they listed then?
    For instance such basics as “Button.background”. (I need this because not all UI elements look good in the default shading of my colors.)
    2.) Inconstency between elements: nimbusBorder is used for trees and textareas — but not for text fields.
    Comboboxes ignore nimbusLightBackground. TabbedPanes ignore almost anything except nimbusBase.
    3.) Imho this doc is poor because it does not state which colors are derived from which, so you can just start guessing around.
    4.) NimbusBrowser.java fail with null pointers, slider demo also does not work
    5.) NimbusthemeCreator.java from project aephyr does not work correctly (elements not updateing), same problem with my own code.

    Setting nimbusBase and nimbusBlueGrey (the latter turning out to be quite important, why dont you put it at the top of the list) also colorizes tree icons etc, which is nice and cool. But some colors just look awful when shaded softly (like Nimbus does in the tabs and tree icons), and I would prefer to set these items to grey instead of my nimbusBase color.
    So how do I change the background color of TabbedPane tabs or the base color of tree icons?
    My colleague tried to replace painters, but this also did not work.

    Sorry for releasing my frustration here, but I am quite disappointed because Nimbus looks so smart and simple at first glance.
    The issues in 2.) make nimbus look like a mess to me.
    Maybe I overlooked things?

  • Juan says:

    This pseudo-hack seems to work with the nimbus look and feel. This piece of code changes the font from all the components (some variables are needed)
    ——————————
    public void changeFont(Font f){
    if (UIManager.getLookAndFeel().getName().toLowerCase().contains(“nimbus”)){
    LookAndFeel lnf;
    try {
    lnf = UIManager.getLookAndFeel().getClass().newInstance();
    FontUIResource uIResource = new FontUIResource(f);
    UIDefaults ddd = lnf.getDefaults();
    for (String s : fontComponentNames){ //fontComponentNames is a list of keys such as “Label.font”,”DesktopPane.font”, etc
    ddd.put(s, uIResource);
    }
    UIManager.getLookAndFeel().uninitialize();
    UIManager.setLookAndFeel(lnf);
    } catch (InstantiationException ex) {
    Logger.getLogger(UIUpdater.class.getName()).log(Level.SEVERE, null, ex);
    } catch (IllegalAccessException ex) {
    Logger.getLogger(UIUpdater.class.getName()).log(Level.SEVERE, null, ex);
    } catch (UnsupportedLookAndFeelException ex){
    Logger.getLogger(UIUpdater.class.getName()).log(Level.SEVERE, null, ex);
    }
    }

    UIDefaults defaults = UIManager.getDefaults();
    FontUIResource uiResource = new FontUIResource(f);
    Enumeration newKeys = defaults.keys();
    while (newKeys.hasMoreElements()){
    Object o = newKeys.nextElement();
    if (o.toString().toLowerCase().contains(“font”)){
    defaults.put(o.toString(), uiResource);
    }
    }
    updateUI(); //this method updates the UI of all components
    }
    ——————————-
    There are some things which are bothering me. First, why i need to create a new instance of nimbus to set the default properties. Second, i need to uninitialize the previous look and feel even if the previous look and feel is the same because nimbus seems to ignore the settings when i run the application.

    I´m using this code to change the look and feel dinamically, even at startup. I´ve tried with other codes, but the fonts aren´t shown properly: the look and feel seems to ignore the settings (typically at startup), or some components use another different font (i think it is the font which i set before the new one)… I hope this helps a bit.

  • Matthew Ramsey says:

    Hey smart peeps….

    I’m trying to conditionally change the button of a color to reflect unsaved changes in a program, ie–change to a custom painter for the “generate” button when there are unsaved changes, and then change back to default when there are not. I was under the impression that this might be possible by changing a LAF property, say some sort of button color (I have a custom JButton class that contains a boolean to determine if the button should be custom painted), but it seems to be a one-way transaction–if I change the color once, I can’t seem to change it again.

    To change the color, I am using the Nimbus overrides method, and I though it would be as simple as…

    UIDefaults overrides = new UIDefaults();
    overrides.remove(“Button.background”);
    overrides.put(“Button.background”, Color.BLUE);
    this.putClientProperty(“Nimbus.Overrides”, overrides);
    this.putClientProperty(“Nimbus.Overrides.InheritDefaults”,
    Boolean.TRUE);
    SwingUtilities.updateComponentTreeUI(this);

    to pull out the old property and change the color…

    What am I missing here? ANY help would be greatly appreciated. :)

    Thanks

    -Matt R

  • Albert says:

    Hi Jasper,

    Thanks for Nimbus, it is the best laf that I have ever seen.

    I could finally get to change the background color of the currently selected tree cell using the following code (no other combination of statements could):

    UIDefaults ud;
    ud = new UIDefaults ();
    ud.put ( “Tree:TreeCell[Enabled+Selected].backgroundPainter”, new CP(Color.red) );
    tr.putClientProperty ( “Nimbus.Overrides.InheritDefaults”, true );
    tr.putClientProperty ( “Nimbus.Overrides”, ud );

    where CP is:

    public void paint(Graphics2D g, Object object, int w, int h)
    {
    g.setColor ( color );
    g.fillRect ( 0,0,w,h );
    }

    Now, I need to change the color, that I have already set, to yet another color. I cannot. It seems that I can specify a Painter only once.

    Am I correct ? I hope I am not.

    • Jasper Potts says:

      Sorry Albert its been 3 years or more since I was working on Nimbus so not really sure. It seems like there might be a bug in the cache that is causing it to not update. Its worth filing the bug. I am not sure if there is any workaround other than keeping a reference to the initial painter you provided then change the internal color in the painter.

  • JOAO GUIMARAES says:

    - Hi Pasper Potts. I’m Java brazilian.

    Set Brazilian On:
    Seria possivel usar o nimbus com desenvolvimento de aplicações web ???? No demais, meus sinceros parabéns por este trabalho tão magnifico.

    Set English On:
    It would be possible to use nimbus with web application development?? In others, my sincere congratulations for this work so magnificent.

  • Dave T says:

    Hi Jasper, excellent work on Nimbus! Having used the Synth look and feel directly I really sympathise with how tricky this stuff can be!

    I was wondering if there had been any progress regarding setting a component laf using the component name? I have been trying for a few days now to get it working but with no success. Also I was reading the source code from Java 7 and the actual string formatting mentioned in the comments appears to differ between the NimbusLookAndFeel and NimbusDefaults files.

    Any help you could offer would be much appreciated!

    Thanks!

    Here comes the code, please let me know what I am doing wrong:

    NimbusLookAndFeel laf = new NimbusLookAndFeel();
    laf.register(Region.LABEL, “\”nonStandardLabel\””);
    UIDefaults ret = laf.getDefaults();
    ret.put(“\”nonStandardLabel\”.textForeground”, Color.GREEN);
    UIManager.setLookAndFeel(laf);

    SwingUtilities.updateComponentTreeUI(WindowManager.getDefault().getMainWindow());

  • Ashutosh says:

    Very useful blog. A question however, with regards to the property on UIdefaults.
    Table.rowHeight is a property that I can set on the UIDefaults and it works.

    However , this is not a key in the UIDefaults. So how does it work ?