JDK-6604357 : Nimbus L&F: Add componet customization via ClientProperties
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u5
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-09-13
  • Updated: 2011-03-05
  • Resolved: 2007-12-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10 b09Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Would like to add the ability to modify what the NimbusStyle reports as values (painters, properties, etc) based on entries in UIDefaults AND in a component's client properties. The current scheme of customizing states based on named components in UI defaults is fine if you have a special named component that will be reused in many places. However, if you are doing a one-off design for a single component, this approach can lead to a polluted and cluttered UIDefaults table. Rather, it would be nice to associate the custom state with the component itself. Lacking public API, I propose using undocumented client properties for Java 6 (and documented properties or public API in Java 7). Any entry in client properties would override the corresponding entry in UIDefaults.

We would also like Nimbus to support the "JComponent.sizeVariant" client property to control component size. The name of the property and its values have been chosen to match Apple's LAF so we are compatable. The valid values for this key are "large", "small" and "mini". They designed to be used in tools pallets where space is a premium and small or mini components are needed or in wizards/dialogs where there is plenty of space and a larger conponents can be used. Look at the attched screenshot to see the effect of this setting. It is not designed to work perfectly with all components, only a few like JButton, JCheckBox, JRadioButton, JTextField, JComboBox, JSpinner, JprogressBar, JScrollBar and JSlider.

Comments
EVALUATION For the "JComponent.sizeVariant" implementation a few aspects of a component need to be scaled. For all components the font size and insets are scaled. Then a few special properties such as "ProgressBar.horizontalSize" also need to be scaled. The special cases are done in the SynthUI deligates for the respective components. The choosen scale factors are "large"=115% "small"=85.7% and "mini"=71.4% these were chosen to match Apple's LAF.
07-12-2007

EVALUATION Also found during debugging that the background colors are not being handled correctly by Synth. SynthStyle hard codes that only when the state is ENABLED (not ENABLED and MOUSE_OVER, or any other combination, only ENABLED) the background color applied by the developer is honored, otherwise it is ignored and the LAF background is used. This is incorrect. As with all other Swing components and Swing look and feels, the background of the component should be honored when set by the developer, regardless of the state of the component. The fix for this bug includes a fix for this background issue. You can see the bad.tiff and good.tiff images to see what has changed. In both cases, the buttons are set to be opaque, and given a background color of RED. PINK is the background color of the parent.
11-10-2007

EVALUATION Implemented as outlined in the description. Specifically, we use "Nimbus.Overrides", "Nimbus.Overrides.InheritDefaults", and "Nimbus.State" client properties. It is extremely unlikely that these client properties are currently in use by any application.
08-10-2007