|
Xtreme - Paradigm
There are many approaches to graphics programming:
Simple but Limited: BGI
The simplest ansatz is used by Borland Graphics Interface (BGI):
it offers a set of commands for "drawing primitives" like lines,
pixels etc. BGI is very intuitive to use, but it's not very
powerful: neither does it provide mouse support, nor multiple
windows. It is also locked to the ancient DOS platform.
Imperatively Inconvenient: Handles and Events
A more powerful approach is taken by (X) Windows and OS/2: multiple
windows are possible by facilitating "handles" and associatied
graphics contexts, which are used for the actual drawing. Depending
on the individual quality of the interface, this kind of graphics
programming is more or less convenient.
It turns out that for beginners, events are a major
stumbling block. Events are used to manage input from the window
(mouse clicks, key strokes) and window commands like redraw and
resize.
The main program consists of an event loop, the program flow
is completely opaque.
Object-Oriented: Hidden Handles and Events
Today, the most popular method to deal with windows are
class libraries. Mostly written in C++ or Java (or maybe C#
in a few years), examples of such class libraries include Troll
Tech's Qt, Inprise' Object
Windows Library (OWL), the Microsoft Foundation Classes (MFC), and
Javasoft's Abstract Windowing Toolkit (AWT) and Swing classes.
These libraries offer class hierarchies for drawing, convenient
dialog design and more. Inheritance allows for powerful
customizations.
Events are hidden behind chains of responsibility or similar
patterns; however, the program flow remains opaque.
The Stream Ansatz
The Xtreme paradigm is fundamentally different. The basic
concept of Xtreme is the data stream. Graphics primitives
like lines are streamed into the window, and key strokes and
mouse clicks stream out. A window is treated like a file, or
more precisely: like a C++ stream, like cin and
cout. Text or graphics objects are written into the
stream, and key strokes are read from it; multiple windows
can be opened at the same time just like multiple files can.
Here's an example:
#include <unistd.h> // for sleep()
#include <xtreme>
main ()
{
int i;
// open a 200x200 window, title "Hello World"
xstream xs ("Hello World",0,0,200,200);
// write some text...
xs << "Hello World!\n";
// a green circle...
xs << Circle(100,100,90,Green);
// a yellow rectangle...
xs << Rect(5,5,195,195,Yellow);
// prompt for input
xs << "Please enter an integer number: ";
// read input
xs >> i;
// write some more drivel
xs << "\n you entered " << i << "\n";
// wait for 5 secs, so user can see the window
sleep(5);
// window is closed when it leaves scope and is destructed
return 0;
}
The central element of Xtreme is the class xstream,
which represents a window stream. Basically it can be used
like a file open for both reading and writing.
Advantages and Weaknesses of Xtreme
The stream ansatz is definitively not the panacea. In fact,
it's usefulness is limited to a rather narrow set of applications.
For example, implementing dialog boxes is a royal pain in
the behind.
Xtreme was designed to allow for straightforward implementation
of things like function plots. This goal has been archieved.
The price for this simplicity is a severe loss in interactivity.
(I'm tempted to say it's xtremely difficult to implement
for instance a menu. Pun intened :-)
Another important design decision was to make Xtreme handle
redraws. This implies that Xtreme must remember everything
that has been written to the stream. Xtreme must store every
circle, line, text or pixel. This implies that while a decent
performance for vector graphics is easily maintained, excessive
pixel graphics will seriously hurt performance. The big advantage,
however, is that the program flow is completely transparent,
as it is for files.
This locks neatly with the Unix philosophy,
"everything is a file".
|