JAVA ACCESSIBILITY
The Pluggable Look And Feel
[Home] [What is it?]
[Overview of Features] [API
Reference]
[FAQ] [Examples]
[Changes]
[Compatibility table]
[JFC Home Page]
Explanation of the Pluggable Look and Feel
The JavaTM
Foundation Classes "Swing" user interface building blocks are designed
around a Pluggable Look and Feel architecture that allows us for the first
time to get away from interpreting the visual manifestations, and instead
"plug in" a non-visual manifestation. This architecture separates the expression
of the user interface from the underlying structure and data on a component-by-component
basis. This is accomplished by separating the user interface of the component
from the "model" of the component (the structure which encapsulates the
state and information that the user interface portion presents to the user).
Prior to the Pluggable Look and Feel, the non-mainstream user had two
options: specialized software closely tailored to their non-mainstream
modality (e.g. a talking web browser), or a specialized access application
(e.g. a screen reader) which interpreted and re-presented the visual presentation
of mainstream applications. With the Java
Foundation Classes and Swing, we now have a third option: direct
presentation in non-mainstream modalities of mainstream applications.
How the Swing classes provide a Pluggable Look and Feel
For each component in Swing, there are actually (at least) five Java programming
language objects that are needed to make that Swing component pluggable.
These are: the component itself (e.g., a button); the Java programming
language interface that defines the user interface (e.g., the button's
UI); a default implementation of that user interface (e.g., the Basic Button);
a Java programming language interface that defines the model of the component
(e.g., the Button model); and finally, a default implementation of that
model (e.g., the Swing Button model).
For most uses of a given Swing component (e.g., a Button), the programmer
doesn't need to know or care about any Swing object other than the first
of the five listed above. The programmer simply creates a new instance
of the first object of the five, and writes code to interact with it. The
others are created automatically based upon the settings on the user's
machine. By default, the choice of which user interface and model to use
is made in the user's preferences files, where an entire "factory" of user-interfaces
and models is specified by the user.
What Swing provides
In order to make it easy to migrate from the user interface classes in
the AWT to the new Swing user interface classes, Swing provides a parallel
set of user interface classes to those in AWT. Each Swing class that has
a parallel in the AWT bears a name that is identical to the AWT name, except
that the letter "J" is prepended to it. Otherwise, each parallel user interface
object contains a superset of the public methods and variables of the corresponding
AWT class. There are roughly 55 user interface building blocks in Swing,
including the common items such as buttons, check boxes, radio buttons,
combo boxes, menus, and labels, as well more sophisticated items such as
tooltips, tabbed panes, tree views, table views, editable text fields,
HTML editors, a Color Chooser, a Money Chooser, etc. Each of these Swing
user interface classes fully supports the Pluggable Look and Feel architecture.
Providing Direct Accessibility in Swing
In order to get direct access to a Swing program via a non-mainstream modality
(e.g., audio, Braille, etc.), the user would need a factory containing
a set of user interface classes installed on their system for each of the
Swing classes listed above. Then the user would need to specify that this
replacement set be used in the appropriate properties file. Finally, the
user would need to run Swing programs that didn't explicitly bar the use
of alternate user interface factories.
In setting this up, the user has three options: complete replacement
of a mainstream user interface with their alternate one(s); having the
mainstream interface and the alternate interface(s) working simultaneously
(e.g., visual and audio) through the use of the special multi-plexing user
interface factory supplied by Sun; or finally, by choosing on a component-by-component
basis which user interface class to use.
Copyright©
1995-98 Sun Microsystems, Inc. All Rights
Reserved.
To submit comments or suggestions about Java
Accessibility, please send mail to access@sun.com.
