In this paper we present an Object Oriented approach for the development of applications requiring both advanced graphics capabilities and a powerful user interface.
The proposed application framework encapsulates both AIXwindows Environment and graPHIGS(*) (the IBM implementations of X-Windows(**) and PHIGS standards) in a coherent programming environment.
A wide tree of C++ classes builds a library of skeleton applications.
From these the developer can inherit a simple "hello world"
program up to a complex "technical map" editor.
This approach has revealed a number of benefits compared to traditional development techniques. The coding time for new applications drastically reduces and there is a cut-off in the learning curve for newcomers. At the same time, the code is shorter, easily extensible and reusable, thanks to the Object Oriented approach.
Currently, the library covers all the needs of 2D graphic programming (the area of our interest). It is in use by groups of developers in Milan and Rome.
KEYWORDS: Object Oriented Programming, C++, graphics, user interface
Graphical applications consist of a part responsible for interacting with the user, and another responsible for processing commands and data[4].
A great part of the code for the interaction and the graphical display consists of the implementation of standard procedures and algorithms. It is an ideal place for the application of object oriented techniques.
Starting from a proper set of classes providing skeletons of user interfaces, complete applications can be inherited adding new functionality and tuning the behavior of existing objects. This is what we call an Application Framework[3].
Many tools and libraries are widely available for applications in computer graphics, under the UNIX operating system and its IBM implementation AIX(*). However, they usually can be classified into one of two distinct classes: on the one hand, X-Windows based tools are commonly used to build graphical user interfaces, with a standard look and feel, but they lack in pure graphical functions; on the other hand, advanced graphics is achieved by libraries (e.g. PHIGS and GL) that do not provide high-level primitives for the user interface, such as buttons, menus, etc.
This paper presents a C++ Application Framework that encapsulates both XWindows and PHIGS in a coherent programming environment. All the features described here have been implemented and used to develop several applications. The package runs on IBM Risc System/6000(*) workstations with AIXwindows and graPHIGS.
Section 2 of this paper analyses the primary goals of the project. Section 3 discusses its overall design. Sections 47 describe the fundamental building blocks. Finally section 8 evaluates the results obtained using the tool. This paper requires a basic knowledge of the concepts of object oriented programming and of graphic programming with XWindows.
This development tool was born within a wider project in the IBM Italian Scientific and Technical Solution Center (STSC hereafter). Here, the image processing group works on automatic recognition of maps and technical drawings[1].
During the interpretation process of a map, some automatic steps need a final interactive check, to confirm the results computed by the system. Therefore, user interfaces providing advanced graphic capabilities must be built.
Moreover, the only way to test and debug algorithms for the automatic interpretation process is to display their results on a screen.
The ultimate goal of this library was to provide a framework both to build 2D graphical user interfaces and to serve as a development and debugging tool for people involved in the automatic recognition of maps.
At the same time, users of the library had no experience in Object Oriented Programming and were not accustomed to the development of user interfaces with X-Windows or of advanced graphical applications with PHIGS.
Thus we identified a set of primary goals:
The architecture of the development tool is divided into different layers (fig. 1)
fig. 1 - Application Framework architecture
At the lower level, two wrappers provide an object oriented interface to the basic AIXwindows and graPHIGS libraries. In this way we get a coherent environment. The users of both the libraries can easily learn how to develop applications within the new environment; actually, the main concepts are preserved in both cases, but their implementation is extremely simplified.
A set of basic classes implements help and error management facilities and other elementary features of general use.
Developers of user interfaces need tools to implement dialogue panels, fillin forms or menus easily. At the same time, most graphical applications have commands to select objects or draw something interactively. Using the firstlevel classes and functions, we have implemented objects of higher complexity to perform these important tasks.
All these classes are of general use, but we have also developed objects and functions specifically tailored to our needs in the field of map recognition.
At the higher level, we have placed skeleton application classes. This is the core of the application framework: in order to develop a real program, the user must choose the more similar sample object and inherit a new class from it. Later, the new object, with its improved functionality, can become the base class for a more complex application.
We will now examine these layers with grater detail.
A library for the development of user interfaces is inherently object oriented, since buttons, menus and windows are "physical" objects that appear on the screen and must be "manipulated" interactively.
Motif and the Xt Intrinsics library are a de facto standard for user interface development in the world of Unix workstations. They support an object oriented architecture, implemented in C through the concept of widget[9,10].
We have decided to develop a set of classes embedding widgets into C++ objects.
We have chosen this approach even though object oriented libraries based over X-Windows are available. In fact many of these libraries, such as Interviews[8], are built over Xlib, the lower X-Windows layer, that does not include widgets. This means that:
We have also preferred to build our own library instead of using other available sets of classes built over Motif widgets, such as the Widged Wrapper Library[3]:they are not well tailorable to our needs, especially in what concerns integrability with graPHIGS.
The tree of the "widget objects"(fig. 2) has its root in the Core_O class, that encapsulates the core widget, and covers all Motif widgets. The hierarchy includes classes obtained in three different ways:
fig.2 - Some classes of the Core_O tree
Every user interface developed with this library requires at least one instance of the class Application_O; this class hides to the programmer XWindows initialization, display handling and a number of boring procedures.
Using only mentioned above first level classes, the traditional Hello World program has the following form:
#include <Core_O.h>
main()
{
Application_O app("app");
Label_O("Hello World", app);
app.Start();
}
The objects that make up the interface are placed in a hierarchy, just as XWindows Toolkit widgets, and the Label_O is a child of the instance of Application_O.
Complex interfaces include a wide tree of object instances (fig. 3).
fig.3 - Sample tree of widget object instances
The main limit of the library is that it does not overlap all the functionalities of Xlib and XWindows Toolkit. This target is well over our possibilities.
In any case, each class is related to the main widget hidden into it. We have developed conversion operators that extract the widget in a way transparent to the programmer. As a consequence, whenever the need arises, it is possible to use XLib and XWindows Toolkit functions easily. We have also provided methods to add new resources to the classes, fully supporting the XWindows Resource Database Manager.
PHIGS is a powerful graphic language[5]. It is versatile and it virtually answers all the needs of a graphic programmer (but not of the user interface developer). It is a difficult language to learn, though, and has a long start up time. The concepts and hierarchies related to the workstations, viewports, windows, views and structures are not readily mastered. The number of routines and parameters is very high but most applications actually use only a subset of PHIGS routines and functionalities.
We decided to choose the most suitable subset for our purposes (2 dimensional primitives and their attributes). We took advantage of the fact that the graPHIGS architecture is suited for an object-oriented implementation.
The first step towards the integration of graPHIGS and AIXwindows has been the development of a widget object to manage a PHIGS workstation. We have obtained this gPWorkstation_O class starting from a sample widget distributed with graPHIGS for the IBM Risc System/6000 workstation.
This class is fully integrated in the Core_O tree and adds a number of specific resources to its ancestor, the DrawingArea_O. It provides a graphic area where the drawing is ultimately performed with graPHIGS. It implements methods, for example, to create and connect a workstation, associate views to it, deal with change of coordinates.
The encapsulation of the graphic language consists of a set of classes, besides the gPWorkstation_O:
All the graphic primitives, beside being methods of the Struct object, appear in the library as functions. Compared to graPHIGS functions, they are much more easily mastered, thanks to a heavy use of overloading and default parameters.
We have chosen this approach for a number of reasons:
In order to integrate XWindows and PHIGS, we had to follow the event driven input model: the application is embedded in the "main loop". X-Windows manages the event queue and dispatches the proper messages to the application, which simply waits for input events. Then, it answers through the callback mechanism[4].
This can require a shift in programming philosophy to the developers used to graPHIGS. In graPHIGS, most programmers design their applications checking constantly the input that the workstation receives (Request or Sample modes), in order to answer with the proper actions. At the same time, the event driven approach can be a problem when porting applications.
On the other hand, the event driven model is the best solution for multitasking environments, since an idle application (one with an empty event queue and waiting for input only) can be suspended by the system preventing wasting of CPU time.
On top of these two wrappers we have developed a wide set of classes. They make the implementation of tasks common to almost every program quite easy. Among these classes, Dialogs, Menus and Fill-in panels are of fundamental importance: they implement the applicationuser dialogue controller, freeing the programmer from the need of handling low level events.
The library has also a set of classes tailored to the needs of mapping applications: the main class is a general purpose map viewer, with navigation functions and the ability of displaying multiple views of the same map. It also provides methods to interact with the objects of the map, such as zooming and panning, making the implementation of a complete map editor an easy task.
Although the lower layers of this library provide an interface of much higher level than Motif and PHIGS, most applications contain a surprising amount of duplicate code.
Considering only the minimum features common to all our applications, it is true that all programs must:
Most programs perform all these tasks with only minor changes. A commonly used approach is to prepare a template with these steps and use a copy of it as the basis of every new program.
A more powerful approach is to capture in a class an application skeleton that performs these steps. Programmers can reuse the common code simply instantiating the class, or deriving a new class from the original one.
We decided to implement this approach because it has several advantages. For example:
The power of this approach becomes evident when we apply it to a specific category of complex applications. Here, it is easy to identify a wide set of common features that we can encapsulate in an application class. It was our case in the automatic recognition of maps.
The library itself provides only a basic set of application classes, but every development group will build its own specific set in a short time. Some of ready made classes are:
The Application Framework is in use by our group since June 1992. Other groups of developers inside and outside the STSC are using it, too.
These colleagues test our work in a useful way, and their feedbacks have driven a number of extensions and changes to the architecture. Thanks to this tuning we have fulfilled the main part or our goals:
In this paper we have discussed our object oriented approach to the development of applications that require both an effective user interface and advanced 2D graphic capabilities.
We have developed a tool that pays attention to the requirements of an industrial research environment: reusability of all the code already developed and fast migration of the programmers to the new techniques are of fundamental importance.
We have found the Application Framework a good answer to our needs; in fact, we often have to develop applications which have many common features, making full use of class inheritance.
Clearly, much work can be done to integrate and solve the issues identified throughout the paper. In particular, we feel the necessity of a better integration of our library with the programming tools available for the IBM Risc System/6000 workstation. A significant step toward the usability of this library would be an interactive user interface builder, mostly for simple interfaces. We will explore these topics in future work.
(*) IBM SEMEA, Risc System/6000, AIX, SAA CUA, AIXwindows Environment and graPHIGS are trademarks of the IBM Corporation.
(**) XWindows is a trademark of Massachusetts Institute of Technology.