Start of Tutorial > Start of Trail > Start of Lesson

Search Feedback Form

More Swing Features and Concepts

This lesson has discussed some of the major concepts you need to know to build Swing GUIs -- the containment hierarchy, layout management, event handling, painting, and threads. Along the way, we touched upon related topics, such as borders. This section tells you about some of the Swing features that we haven't yet discussed:

• Features that JComponent provides
• Icons
• Actions
• Pluggable Look & Feel support
• Support for assistive technologies
• Separate data and state models

Features that JComponent Provides

Except for the top-level containers, all components that begin with J inherit from the JComponent class. They get many features from JComponent, such as the ability to have borders, tool tips, and a configurable look and feel. They also inherit many convenient methods. For details about what JComponent provides, see The JComponent Class.

Icons

Many Swing components -- notably buttons and labels -- can display images. You specify these images as Icon objects. See How to Use Icons for instructions and a list of examples that use icons.

Actions

With Action objects, the Swing API provides special support for sharing data and state between two or more components that can generate action events. For example, if you have a button and a menu item that perform the same function, consider using an Action object to coordinate the text, icon, and enabled state for the two components. For details, see How to Use Actions.

Pluggable Look & Feel

A single program can have any one of several looks and feels. You can let the user determine the look and feel, or you can specify the look and feel programatically. See How to Set the Look and Feel for details.

Support for Assistive Technologies

Assistive technologies such as screen readers can use the Accessibility API to get information from Swing components. Because support for the Accessibility API is built into the Swing components, your Swing program will probably work just fine with assistive technologies, even if you do nothing special. With very little extra effort, however, you can make your program function even more smoothly with assistive technologies, which might well expand its market. See How to Support Assistive Technologies for details.

Separate Data and State Models

Most noncontainer Swing components have models. A button (JButton), for example, has a model (ButtonModel) that stores the button's state -- what its keyboard mnemonic is, whether it's enabled, selected, or pressed, and so on. Some components have multiple models. A list (JList), for example, uses a ListModel to hold the list's contents, and a ListSelectionModel to track the list's current selection.

You don't usually need to know about the models that a component uses. For example, almost all programs that use buttons deal directly with the JButton object, and don't deal at all with the ButtonModel object.

Why then do separate models exist? Because they give you the ability to work with components more efficiently and to easily share data and state between components. One common case is when a component, such as a list or table, contains lots of data. It can be much faster to manage the data by directly working with a data model than by having the component forward each data request to the model. You can use the component's default model, or you can implement your own.

For information about models, see the how-to pages for individual components. Also, The Anatomy of a Swing-Based Program discusses some custom models used by that section's featured program, Converter.

Start of Tutorial > Start of Trail > Start of Lesson

Search Feedback Form