Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

Being Prepared for New Developments in Computer Graphics

The several benefits of our current design and of our adopted software should be clear to see. They come, though, with a possible cost: will AIPS++ be so strongly tied to these choices that we will be unable to pursue compelling or dominant new techniques, tools, and operating systems as they come along? There are at least three areas of concern:

1.

A graphics toolkit with embedded interpreter (i.e., the recently popular TCL/TK)

2.

New (or newly important) toolkits and graphics libraries: Fresco, OpenGL, OpenInventor

3.

Windows NT, Plan 9, Taligent

It is quite possible that some new graphics system, widget toolkit, or operating system will sweep the scientific community in the next 5-10 years, offering so many gains in efficiency and expressiveness that our software will become obsolete. But it is inconceivable that this would happen without there first being some time in which the new and the old systems co-exist, and in which we could mix and match tools according to our best judgement. More specifically:

1.

TCL/TK is not yet mature enough to be used for all of our graphics needs.³ Its primary virtues appears to be its embedded interpreter, and the resulting ease with which casual programmers can construct and configure an interface. If this end-user configurability becomes a requirement for AIPS++, it would be possible to add TCL/TK to our graphics tools, though it is unlikely that we would choose to do so: TCL's only data type is character strings, and as an interpreter, it is much less powerful and elegant than glish. Some limited end-user configurability could be easily accomplished with resourceful use of glish and Motif. Still, TCL/TK could be added if there were a compelling reason to do so.

2.

In the past, a lot of very interesting user interface programming has been done with InterViews. It's likely that related work will soon be done with Fresco - indeed, Fresco offers many features (graphical embedding, arbitrary geometric transformations) that make it ideal for constructing powerful user interfaces, and it may become very important in years to come.⁴ Fortunately, and even at this early stage, Fresco glyphs and OpenGL canvases can be built inside ordinary Xt widgets. We would have no difficulties adding Fresco to the AIPS++ graphics infrastructure if we had the need to.

3.

Even at this early date in the (perhaps oversold?) career of Windows NT, X window servers are plentiful. One can presently buy compatibility toolkits for Windows 3.1, allowing Motif programs to compile and run unmodified. There is every reason to believe that this trend will continue. The same can be said of other new Operating Systems.

The best protection against obsolescence is to keep the implementation details out of the public interface. Client code, then, will not need to change very much when circumstances dictate that (for example) a new graphics library or widget kit should be used. We try to hide the implementation in the C++ classes, but cannot always succeed: see, for example, in the next section the appearance of X widgets in the constructors for the ImageDisplay class. The glish event interface, however, can and will be protected from the implementation details of a particular graphics system.