Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
1997-06-30
2002-12-17
Huynh, Ba (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000
Reexamination Certificate
active
06496202
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates graphical user interfaces, and, more specifically to the generation of components of a graphical user interface.
2. Background Art
A software application typically includes a graphical user interface (GUI) for displaying the application's output and receiving user input that consists of GUI components. Examples of GUI component types include menu, scroll bar, text field, button, check box, list, and label. There are a number of software vendors that have developed GUI libraries that consist of software modules that implement GUI components. Mechanisms are provided to access a GUI library to incorporate the desired GUI component from the library for use with the software application to generate a piece of the application's GUI. The mechanisms currently available for accessing a vendor's GUI library limit the application developer to one GUI library. That is, it is impossible to intermingle one vendor's GUI components with another vendor's GUI components. Further, it is impossible to customize an application's GUI by replacing one component of the GUI with another GUI component.
One technique, or mechanism, that has been used in the object-oriented environment for accessing a vendor's GUI library is referred to as the factory technique. A factory creates or produces objects at runtime. The factory technique is described below with reference to an abstract factory. implementation and a factory method implementation. Neither the abstract factory nor the factory method implementations allow a software application to intermingle GUI components from different vendor's GUI libraries.
Abstract Factory
An abstract factory is implemented in an object-oriented environment using factory and product abstract classes that define the operations or methods to be implemented by their concrete subclasses. The factory includes methods that are used to create an instance of a product concrete subclass. A product concrete subclass is a specific GUI component and includes the GUI component's operations.
An abstract factory can be used, for example, to allow an application developer to write a software application that contains references to the GUI components of a generic GUI library. At run time, the GUI library is specified and the GUI component references are resolved to refer to GUI components in the specified GUI library. Using this technique, a software application can be written to use one GUI library's GUI components (e.g., Motif GUI components) in one runtime environment and another GUI library's GUI components (e.g., Presentation Manager GUI components) in another runtime environment.
To instantiate Motif's scroll bar without using the abstract factory technique, the following C++ code can be used:
(1) ScrollBar* sb=new MotifScrollBar;
The above code statement is not advantageous because it hard-codes the Motif standard into the application. Instead, the following code can be used to create a scroll bar GUI component:
(2) ScrollBar* sb=guiFactory−>CreateScrollBar( );
In this case, guiFactory can be an instance of either the MotifFactory or the PMFactory concrete class both of which are subclasses of a GUIFactory abstract class.
FIG. 1
provides an example of the abstract product classes and concrete subclasses used in the abstract factory design pattern. There are three abstract classes, GUIFactory
102
, Menu
112
and ScrollBar
122
. Since they are abstract classes, they are not instantiated at runtime.
GUIFactory
102
is an abstract class that specifies methods for creating GUI components (e.g. scroll bar, window, and button) such as the CreateMenu and CreateScrollBar methods. GUIFactory
102
is referred to as a factory because it specifies methods for producing objects. Subclasses of GUIFactory
102
define a specific implementation of the methods defined by GUIFactory
102
. Two subclasses of GUIFactory
102
which are concrete factories (i.e., create concrete product objects) are MotifFactory
104
and PMFactory
106
. MotifFactory
104
provides a Motif-specific implementation of the same method in GUIFactory
102
. PMFactory
106
defines a Presentation Manager-specific implementation of the method.
One of the concrete factories is instantiated at runtime based on the look-and-feel standard that is specified (e.g., as a runtime parameter). If, for example, the look-and-feel standard is determined at runtime to be Motif, an instance of MotifFactory is instantiated. The second code statement provided above would have the effect of invoking the CreateScrollBar method or operation of the MotifFactory object which would create a scroll bar having the Motif look-and-feel.
The other two abstract classes, Menu
112
and ScrollBar
122
define the methods that are implemented by a concrete subclass. For example, MotifMenu
114
and PMMenu
116
define specific implementations of the Popup operation defined by Menu
112
based on their respective look-and-feel standards. Similarly, the ScrollTo operation defined in the Scroll Bar
122
abstract class is implemented by MotifScrollBar
124
and PMScrollBar
126
. In the above example, the second code statement would invoke the CreateScrollBar method of MotifFactory
104
that would result in the creation of an instance of MotifScrollBar
124
.
The abstract factory uses factory and product abstract classes to define the methods that are implemented by their respective concrete classes. An application does not directly instantiate classes. Instead, objects can be instantiated indirectly as illustrated by the second code statement. The application effectively uses a pointer to the object to be instantiated that is resolved at runtime.
The abstract factory mechanism thereby eliminates the situation where the application is forced to use one look-and-feel standard or another. However, the application must select one look-and-feel standard and use only that standard's GUI components. It is not possible, for example, to have both a scroll bar that has the Motif look-and-feel (i.e., MotifScrollBar
124
) and PM scroll bar (i.e., PMScrollBar
126
) GUI component in the same application using the abstract factory mechanism. Further, all of the classes are defined for the application prior to runtime. Thus, it is not possible to modify the class architecture by inserting, for example, new subclasses of Menu
112
or ScrollBar
122
at runtime.
Factory Method
In the abstract factory approach, a factory object is instantiated that knows the type of product objects that can be constructed. The product object's constructor is used to construct the product object. Another factory mechanism that has the same drawbacks as the abstract factory is referred to as a Factory Method. The Factory method is implemented by specifying in the abstract object a call to a method that creates the product instead of calling a constructor. The function that creates the product object is referred to as a factory method because it “manufactures” (or creates) the product object. The factory method is used instead of a constructor to create a product object.
FIG. 2
provides an example of a factory method class architecture.
The architecture in
FIG. 2
illustrates a framework that produces GUI components from a vendor's GUI library of GUI components. There are two abstract classes, an abstract creator class (i.e., GUI
202
) and an abstract product class (GUIComponent
212
). GUI
202
includes a factory method declaration (i.e., createUI). However, GUI
202
does not know what type of product it should create (i.e., GUI
202
cannot call a constructor method for MotifComponent
214
or PMComponent
216
).
The factory method of GUI
202
is redefined in two concrete creator object subclasses of application
202
(i.e., MotifUI
204
and PMUI
206
). MotifUI
204
defines a createUIComponent factory method to create an instance of MotifComponent
214
. Similarly, PMUI
206
defines a createUIC
Huynh Ba
Martine & Penilla LLP
Sun Microsystems Inc.
LandOfFree
Method and apparatus for generating a graphical user interface does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for generating a graphical user interface, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for generating a graphical user interface will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2981776