Table of Contents
The Tweek Java GUI uses JavaBeans to be more flexible and accessible to programmers. The GUI is a framework into which graphical and non-graphical components may be “plugged”. Graphical components add interaction functionality. Non-graphical components extend internal functionality, oftentimes needed by the graphical components. Conceptually, this follows the traditional use of plug-in architectures wherein the components are discovered dynamically and added into the larger framework. In the case of the Tweek Java GUI, the plug-ins will fit into one of four categories, the most important of which is Panel Bean.
There are four types of Beans that may be loaded by the Tweek Java GUI. They are categorized based on functionality and what is known about them in advance. The following lists the four categories in order of decreasing a priori knowledge.
Service Beans
Viewer Beans
Panel Beans
Generic Beans
Services encapsulate functionality that may be useful to other parts of the Tweek system or dynamically loaded code. The entire interface for Service Beans must be known when the code using the service is compiled. This is because the using code needs to be able to take advantage of the service. Because Service Beans may be loaded dynamically, using code must be prepared for the case when the Bean containing the service was not found. In other words, code that uses services cannot necessarily assume that the service will be available.
Not all services are loaded dynamically as Beans. Some services are loaded statically because they are needed by core components. These include the Environment Service and the Global Preferences Service. There is a guarantee that the code for these services will always be available. This guarantee is especially important because the Tweek core needs to add information to the Environment Service at startup. The Global Preferences Service is needed to configure the overall behavior of the Tweek GUI.
Viewer Beans provide a rendering of the tree of Panel Beans (discussed next). They provide the viewer component of the model/view pattern [Gam95]. All Viewer Beans are loaded dynamically, and the active viewer can be changed at runtime by editing the global preferences. This feature is realized through the flexibility of the model/view pattern.
Viewer Beans must implement the
org.vrjuggler.tweek.beans.BeanModelViewer
interface. To simplify implementation, they may be derived from
org.vrjuggler.tweek.beans.DefaultBeanModelViewer,
a class that implements aspects of the interface that are unlikely
to vary between viewer implementations. The use of the interface is
needed so that the GUI frame can assume certain behaviors about the
viewer.
Most programmers using Tweek will write Panel Beans. These provide custom interfaces for whatever users need. In most cases, a Panel Bean will provide a graphical interface that can manipulate and/or control a C++ application, but developers are not strictly limited to this use.
Only one assumption is made about Panel Beans: the primary
class for the Bean must be a subclass of
javax.swing.JComponent. Optionally, the
primary class may implement one or more publicly provided interfaces
that provide the Java GUI with more information about the
capabilities of the Bean. When loaded, the GUI checks to see what,
if any, interfaces are implemented by the Bean. Based on the
results, special actions may be taken to provide the Bean with
extended functionality.
For example, Beans that can load files should implement
org.vrjuggler.tweek.beans.FileLoader.
When the Bean is focused in the viewer, the
menu will be modified to enable the ,
, and
items. If the user selects one of
these items, the Bean is informed and can take appropriate
customized actions. The result in this case is context-specific
loading and unloading of files.
Nothing at all is assumed about Generic Beans. This Bean category is provided so that other Beans can do their own dynamic code loading. For example, a Bean that uses a factory pattern may want to have the “workers” loaded dynamically based on some criteria. Thus, the functionality of the factory can be changed dynamically.
The Tweek Java GUI does not use Generic Beans itself. These are provided more for users of the Tweek Java API. It is up to those programmers to decide how to handle the Generic Beans on a case-by-case basis.