Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Subsections

• Low-level Interface: gDisplay.so
• High-level Interface: the Viewer

The Glish Connection

Low-level Interface: gDisplay.so

The glishtk proxy client has been chosen as the (current) vehicle to provide the Display Library services to the AIPS++ user. This facility has been provided this way so that Display Library canvases could be embedded in the AIPS++ graphical user interface elements which were already supplied by by the glishtk proxy client. Additionally, the nature of glishtk enables the Display Library services to be loaded dynamically into an already-running client. Had the interface been implemented more along the lines of the existing Glish distributed-object mechanism, then the canvases of the Display Library would be confined to their own window/s and display tools would have been unable to exploit the graphical user interface elements (eg. buttons, menus) already provided by glishtk.

To this end, the major components of the Display Library have been collected into a dynamically loadable Tcl module, known as gDisplay.so. At run-time, this module can be loaded into memory and be incorporated into glishtk's execution thread using Tcl's dynamic loading facility. Ideally, a transparent interface could be written to provide constructors, methods and destructors for each class in the Display Library, and then instances of any of the Library classes could be constructed and built from Glish, which of course controls the glishtk client itself. However, this approach seemed too fine-grained, and would result in a moderately heavy burden on the Glish programmer who wanted to produce a simple visualisation application. Therefore, the agents which have been implemented in gDisplay.so are at an even higher level than the top-level Display Library tools, and thereby provide more convenient but less capable interfaces to the Glish programmer. In the future, this design decision should be revisited.

The agents which are presently implemented in gDisplay.so include:

• pixelcanvas, a basic interface to put a PixelCanvas in a Tk frame,
• pspixelcanvas, a very simple interface to create a PostScript PixelCanvas which can be used for saving displays of data,
• worldcanvas, which is a compact representation of the union of a WorldCanvas object and a WorldCanvasHolder object, and which can be constructed upon a pixelcanvas or a pspixelcanvas,
• displaydata, which is a moderately sophisticated agent capable of creating several distinct implementations of the DisplayData base class, and performing operations on such,
• colormap, which is a compact agent managing a single colormap, which can be edited from Glish and attached to displaydata agents,
• animator, which is a simple agent for managing animation operations on worldcanvas agents, and
• drawingdisplaydata, which is an agent in development for doing simple drawings on a worldcanvas agent from the Glish command-line or a Glish script.

The source code for the gDisplay.so module can be found (at the moment) in trialdisplay/apps/gDisplay, and is moderately compact. Typically the source code files in this directory are implementations of the Proxy class which is defined in the Glish sub-system, and the simplest example to peruse initially is the GTkColormap class. The Proxy class implementations simply provide construction, destruction and a selection of event interfaces which are accessed from Glish.

High-level Interface: the Viewer

The raw interface to the gDisplay.so module loaded into the glishtk client is not a particularly convenient one for building up visualisation and display tools at the AIPS++ level. To address this, the proxy agents of gDisplay.so have been ``wrapped up'' with a substantial layer of Glish code. This code (where possible) enforces correct use of the proxy agents, and reinforces the object-oriented nature of the display library. It is very important to realise that the Viewer code is merely one possible implementation of the gDisplay.so proxy agents, and others which look quite different to the programmer and end-user are easily imaginable.

One very important feature of the Viewer interface is that it unifies pixelcanvas and worldcanvas agents. As the worldcanvas proxy agent combined the WorldCanvas and WorldCanvasHolder classes, the viewerdisplaypanel combines the worldcanvas and pixelcanvas agents into one entity. The viewerdisplaypanel is at the time of writing probably the highest-level object in the entire chain of AIPS++ display services. The viewerdisplaypanel is a valid AIPS++ tool, and thus provides method-oriented interface to control its various and many attributes. Construction arguments for the viewerdisplaypanel include width and height settings, foreground and background colors, colortable types ('index', 'rgb', 'hsv'), colortable dimension/s, and flags indicating what user interface elements should be used to adorn the display area itself. Available interface elements include a menu bar, a control bar for selecting and controlling interaction with the display, a button bar, and a tapedeck for controlling animation of the display. Most importantly, the viewerdisplaypanel can be placed in an existing GlishTk frame, thus enabling the embedding of visualisation applications in existing and new AIPS++ tools.

The viewerdisplaydata is the AIPS++ tool which can be used to manage the displaydata proxy agents of gDisplay.so. It is a moderately clean interface, wherein most methods provided to the user are sent directly on to the proxy agent code in gDisplay.so. Viewerdisplaydata tools may be freely registered and unregistered on viewerdisplaypanel tools. A top-level tool, the Viewer, is provided to assist in constructing and managing the various viewerdisplaypanels and viewerdisplaydatas, and so a rudimentary, but quite powerful, visualisation application can now be expressed this simply:

- include 'viewer.g'
- mv := dv.newdisplaypanel();
- mdd := dv.loaddata('test.im', 'raster');
- mv.register(mdd);