 | |
|
The Truffle graphical toolkit was designed to meet several requirements. It supplies an AWT peer set written in the Java programming language. Furthermore, it provides a framework for supplying alternate look & feel designs that are targeted at different kinds of platforms, including consumer devices and desktop systems. This section describes how the Truffle graphical toolkit's architecture supports these goals. The figure below illustrates the major components of the Truffle graphical toolkit's architecture and compares them with desktop implementations of the JDK. The Truffle graphical toolkit fulfills the goal of providing a cross-platform GUI toolkit by providing a set of peer components and the window and graphics system necessary to support them. The Truffle graphical toolkit plays the same role in a Java application environment like the PJAE that native peer sets perform in desktop implementations of the JDK. In fact, the Truffle graphical toolkit can be used to replace these native peer sets. It is much easier to understand the Truffle Graphical Toolkit's purpose and design by thinking of the Truffle Graphical Toolkit in its relationship with the AWT rather than seeing it as sitting on top of a window and graphics system. The reason lies in the Truffle Graphical Toolkit's goal of providing just enough GUI services to meet the requirements of the AWT. In other words, the Truffle Graphical Toolkit is not a general-purpose GUI toolkit with a large number of widgets like Motif and JFC. It is specifically designed to support the API requirements of the AWT and the human-interface needs of consumer devices. Truffle Graphical Toolkit Architecture [Click on image for larger view]
The Truffle Graphical Toolkit uses the Model-View-Controller (MVC) architecture to organize the peer set implementation into groups of classes that perform different roles:
MVC is an example of a design pattern. See Design Patterns: Elements of Reusable Object-Oriented Software. for a more thorough introduction to design patterns.
MVC allows effective use of code sharing
that leverages functionality
between components and thus reduces code size.
From a licensee's perspective,
OTK reduces the software development task
for creating a platform-specific look & feel design
by focusing effort on the appearance and behavior
of the peer components and avoiding the implementation
of the underlying support systems.
Configure TouchableThe term configuration is used to indicate ways in which Touchable can be changed without many source code changes. Touchable was designed to be configurable in two ways:
Modify TouchableModifying Touchable is the most common approach to developing a new look & feel design. This involves a moderate amount of source code changes. Here are some possible scenarios:
Build an OTK-based ToolkitDeveloping an entirely new toolkit based on OTK is a significant amount of work. This approach usually indicates that some architectural goal of the new look & feel is not being met by Touchable and it is better to start from scratch. Even so, it is still best to have a solid understanding of the Touchable implementation before starting on a new toolkit.
OTK contains the minimal common subset of toolkit functionality.
Therefore, a full Truffle-based toolkit requires substantially more
than the functionality that sun.awt.otk provides.
For example,
the ColorPolicy,
DrawUtils and TouchableToolkit classes
are all outside of sun.awt.otk.
In addition,
licensees can use OTK to build product-specific look & feel designs
that support their product identity or product design needs.
This can be done by modifying an existing design like Touchable
with a different color scheme
or by developing a new look & feel design from scratch.
| |||||||||||||||||||
|
| ||||||||||||
Print-friendly Version
