About look and feel
“A term used in software design, in respect of a graphical user interface and comprises aspects of its design, including elements such as colors, shapes, layout, and typefaces (the “look”), as well as the behavior of dynamic elements such as buttons, boxes, and menus (the “feel”). The term can also refer to aspects of an API, mostly to parts of an API which are not related to its functional properties. The term is used in reference to both software and websites”. (Wikipedia)
Smart Client Look and Feel
The “look and feel” (LAF) describes the appearance of UI components. It handles presentation for Smart Client UIF custom controls & states.
It works in conjunction with currently active Swing’s look and feel and Swing’s controls (Only Windows XP LAF supported).
Style Sheet Properties
The Smart Client Look and Feel is defined in a style sheet properties file named style.properties.
How does it work?
Each UI control has a ‘style’ property where a style name can be specified.
Corresponding styles must be pre-defined in the properties file (style.properties).
Control’s style can be changed at runtime using the method UifControl.setStyle(String style). This method is used to set a named style for the control. Once invoked, the control appearance is adjusted according styles defined in the style sheet
Client appearance can be customized through
- Style sheet
- Look-and-feel mechanism.
Style Sheet Properties file
The style sheet properties file is a text file named “style.properties” which contains styles definitions. The properties file is located at the application’s root package (at the same location as “workspace.xml”).
Only one style sheet file allowed per workspace. The style sheet inherits the locale support provided by java.Util.Properties, as well as predefined ‘base’ styles. A user style can extend or override default style definitions (styles defined at the end of the file have higher precedence over settings in the top of the file.
Swing Look and Feel
The Swing look and feel includes settings for UIResource classes for fonts, colors, dimensions, insets, and images.
The settings in the Swing look and feel are passed to javax.swing.UIManager which manages javax.swing.UIDefaults.
Changes to the Swing look and feel can be done at the global level or the control level.
The statements for the Swing look and feel in the properties file start with a plus sign (“+”)
Syntax: Property name (“font”, “color”, “dimension”, “inset”, or “image”) must be specified after the equals sign, followed by the value enclosed in parentheses:
Examples of Swing look and feel global level statements
These settings override the Swing look and feel global level settings. You specify Swing component names without the “J” prefix (such as “Button” for “JButton”).
These are examples of statements for the Swing look and feel at the control level:
Each control has a property where a style name can be specified.
Corresponding styles must be pre-defined in the properties file.
The style settings override the Swing look and feel global and control-level settings.
The style statements follow this format:
The name of the style you specify as a property of the control.
Use an asterisk (“*”) as a wildcard to apply the setting to all styles.
The type of control (a subclass of UifControl);
This name is the same as the control’s class name without the “Uif” prefix.
Use an asterisk (“*”) as a wildcard to apply the setting to all controls.
This value is case insensitive.
The name of the visual attribute such as font, foreground, background, or border.
For border, the attribute may have further sub-attributes.
Multiple sub-attributes are defined by repeating the style and adding “.” followed by the sub-attribute name.
is the name of a sub-attribute (such as the bevel type for a border).
This is a complete example for a style called address:
address.label.font=Dialog 20 address.label.background=#ffff0f address.label.foreground=#fff0ff address.label.border.style=bevel address.label.border.type=lowered
Example of using a wildcard to set the default background color for label controls that use any style:
Example of using a wildcard to set the default background color for any control
that uses the address style:
Example of using a wildcard to set the default background color for all styles and all controls:
Style statements use this precedence (from lowest to highest):
In general, settings in the bottom of the properties file have higher precedence than settings in the top of the file (“last one wins”)
Predefined styles that are used to indicate state:
The predefined styles are only relevant to input objects.
- Do not define your own style names that start with a dollar sign (“$”).
- The overlay Icon attribute specifies the icon associated with a state.
- The icon is painted at the top-left corner of the control and is 8×8 pixels.
- The path is relative to the location of the properties file.
Examples of setting the predefined styles:
Look and Feel Notes
On Windows XP, if a user selects an “XP” color scheme (such as “olive green”) in the Control Panel:
- The application does not inherit the setting in the title of toolboxes and menu bars.
- If a user selects a “classic” color scheme (such as “Rose”), the application does inherit the setting.
- If you make a global font change in style.properties as *.*.font=Courier 20, all controls inherit the setting except menu items, tab text, and group box titles.
The Following attributes are supported for all controls:
Following borders are supported:
To specify this, set the “class” sub-attribute to “bevel” and provide following additional sub-attribute values.
The default is lowered border if type is not specified. All of either highlightOuterColor, highlightInnerColor, shadowOuterColor and shadowInnerColor; OR highlightColor and shadowColor, should be provided to paint the border with the required colors.
To specify this, set the “class” sub-attribute to “empty” and provide following additional sub-attribute values.
- All of the above attributes should be provided to create the border with empty spaces.
- The default is a border with no spaces
To specify etched border, set the “class” sub-attribute to “etched” and provide following additional sub-attribute values.
- The default is lowered border if type is not specified.
- Both, highlightColor and shadowColor should be provided to paint the border with the required colors.
To specify line border, set the “class” sub-attribute to “line” and provide following additional sub-attribute values.
- Color is mandatory.
- The thickness is 1 if it is not specified.
To specify matte border, set the “class” sub-attribute to “matte” and provide following additional sub-attribute values.
- Top, left, bottom, right are mandatory and are used to specify the spacing.
- Either color or tileIcon should be specified.
To set title for any of the above border border, provide following additional sub-attribute values.
Control Specific Styles
The following attributes apply to specific types of controls.
Grid, Search Grid, Hierarchical Grid & Hierarchical Search Grid
In addition to above, following apply:
- The controls used to render cells in the grid cells can be styled via the standard styles with exception of overlayIcon.
- The default style value for the controls when placed in grid is “$gridCell” until overridden via “style” property.
- The tree column in hierarchical grid and hierarchical search grid can be styled using following control names:
- gridtree – represents the column
- treenodecontrol – the node
- Note that border and rowHeight are not supported for gridtree. Setting these properties on gridtree can generate unpredictable results.
Tree Node Control
Note: Tree.expandedIcon & Tree.expandedIcon Swing level properties can be used to change icons for handles used in tree to expand or collapse the node.
Checkbox & Radio Button
Smart Client predefines and uses styles to customize its predefined states. These styles always have names beginning with a “$” sign. Users are advised to avoid names beginning with “$” for their styles. Currently, following styles are being used:
In addition to the styles described above, the style sheet allows storing name value pairs which are used to control behavior both by ASCF and by Swings’ active Look and Feel. These pairs are prefixed with a “+” sign, and the name and value are separated by an equal sign. The name-value pairs are transferred to an internal cache (Swing’s UIManager) from where ASCF and the Look and Feel system can pick up the values and consume them. This allows customization of certain aspects of the look and feel using this style sheet.
The following rules apply:
- Swing attribute names are defined by Swing’s Look And Feel implementations and are not listed here
- ASCF-specific attribute names are listed in the table below
- Supported value types are a subset of the available Swing UIResource classes: i.e. string, int, boolean, font, color, dimension, insets and image
- The format for specifying the values is – <type> ( value ) – i.e., specify the type which is one of int, boolean, font, color, dimension, insets and image, followed by value enclosed between round brackets. String values should be entered as is, without any type notation
- Values for font & color: use same notation as defined above for regular styles
- Values for dimension: comma separated values for width & height
- Values for insets: comma separated values for top, left, bottom & right
- Values for image: url to the image relative to the style sheet
- Support for copying other property values via use of “copy” type.
implies copy the value defined by property “TextField.font” into “FormattedTextField.font”
- Arbitrary attribute names can be used as “variables” to set values which are subsequently used to set other attributes, using the “copy” syntax described above
- Attributes set by custom style sheets override settings in baseline style sheets
The following attributes are supported for ASCF controls:
Sample Style Sheet
# A custom style created to format label control that show address address.label.font=Dialog 20 address.label.backgroundColor=#ffff0f address.label.foregroundColor=#fff0ff address.label.border.style=bevel address.label.border.type=lowered # display required fields in yellow background $required.*.backgroundColor=#ffff00 # Icons for following # Example of overriding special styles $modified_valid.*.overlayIcon=icons/modified_valid.gif $modified_invalid.*.overlayIcon=icons/modified_invalid.gif $alert.*.overlayIcon=icons/alert.gif # FormLayout Customization # Example demonstrating setting Swing UIManager property # In this case, a new property is being set, so we use the insets prefix to # indicate that the value is an inset UIResource +FormLayout.insets=insets(1,2,1,2) # Sample font modification via UIManager defaults # Example demonstrating setting Swing UIManager property. # In this case, BasicLookAndFeel defines the value of the property # so qualification of the value using a prefix is optional. +Label.font=font(Arial 9) # Following is effective in Metal L&F +Tree.expandedIcon = image(icons/lookup_control_disabled_invalid.gif) +Tree.collapsedIcon = image(icons/lookup_control_enabled_valid.gif)
Merging and Overriding of Styles
Style objects are maintained internally such that they are applied to controls in following order:
- First all applicable *.*.<<any attribute>> styles are applied.
- Next all applicable *.<<any control>>.<<any attribute>> styles where an actual control type is specified are applied.
- After this, all applicable <<any style value>>.*.<<any attribute>> styles where an actual style value is specified are applied.
- Finally remaining applicable <<any style value>>.<<any control>>.<<any attribute>> styles are applied.
- If more than one style is applicable to a control, they all are applied in the order mentioned above.
- This provides merging & overriding effect to styles.
- This means that the last style’s attributes has overriding effect over previously applied styles.
- If two styles are applied which do not have common attributes, the result is a combination of both styles.
- The above does not apply to sub-attributes.
- At the time of loading, sub-attributes are immediately merged into a single style object.
- The priority order of the sub-attributes is the same as the priority of the first style defined with the same style and control name.
- Style sheet inherits locale support provide by java.util.Properties.
(java.util.Properties used by style sheet and for loading it at runtime).
- Some of the attributes may not work depending on the limitation of the underlying Swing Control’s UI Delegate implementation
e.g., On JDK 1.5 Windows XP, JButton’s use XP’s system level API to generate background image. These images override most of the JButton’s background area and hence background color does not have any effect.
- *.*.attribute=value may not actually affect all controls. Only UIF controls are guaranteed to be supported for styling
- The following controls are not supported for regular styles:
MenuBar, MenuItems, Popup Menus, etc. cannot be stylized via regular styles.
- Use “+” styles instead to customize these controls.
- The following controls are not supported for regular styles:
- Certain attributes of controls, e.g., group box title, tab control title etc may not respond to regular styles. e.g., forgroundColor when set on a control does not modify the group box title since borders need to be customized by via their own attributes.
No comments yet.