1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
|
<HEAD>
<TITLE> A Portable GUI Development System---The IRAF Widget Server </TITLE>
</HEAD>
<BODY><P>
<h5><hr> Astronomical Data Analysis Software and Systems IV<br>ASP Conference Series, Vol. 77, 1995<br>Book Editors: R. A. Shaw, H. E. Payne, and J. J. E. Hayes<br>Electronic Editor: H. E. Payne <hr> </h5>
<H1><A NAME=SECTION021900000000000000000> A Portable GUI Development System---The IRAF Widget Server</A></H1>
<P>
<P><b>D. Tody</b><br>
National Optical Astronomy Observatories, P.O. Box 26732,
Tucson, AZ 85726<br>
<P>
The National Optical Astronomy Observatories are
operated by the Association of Universities for Research in Astronomy, Inc.
(AURA) under cooperative agreement with the National Science Foundation.
<P>
<P>
<A NAME=1229> </A>
<A NAME=1230> </A>
<A NAME=1231> </A><A NAME=1232> </A>
<A NAME=1233> </A>
<A NAME=1234> </A><A NAME=1235> </A><A NAME=1236> </A><A NAME=1237> </A>
<A NAME=1238> </A>
<A NAME=1239> </A>
<A NAME=todyd> </A><H3>Abstract:</H3>
<EM>We describe a new GUI (Graphics User Interface) development environment
which extends the X window system and the X Toolkit (Xt) with a high-level,
object-oriented, interpreted programming language.
This approach will allow GUIs written
using standard Xt-based widget sets to be constructed without requiring any
window system programming on the part of the programmer.
The architecture of the resulting program completely separates the GUI from
the applications code, allowing the GUI to be developed separately and
replaced at will without modifying the application.
Despite the separation of the GUI from the application the two are tightly
integrated using an asynchronous, event-driven messaging system based on
requests and client events, with the remote client application appearing as
just another class of object within the GUI.
This approach maximizes window system and toolkit independence and is well
suited to distributed applications, allowing the GUI and client application
to be run easily on separate processors or computers.
<P>
</EM><P>
<H1><A NAME=SECTION021910000000000000000> Introduction</A></H1>
<P>
Most window system programming today is done via one of two approaches. The
first approach is to code directly in C or C++ at the window system toolkit
level, usually integrating the user interface code and applications code
within the same program. The second approach, which is really just a
variation on the first, is to use one of the many commercial GUI builders
available. This simplifies the programmer's task by allowing the user
interface to be interactively designed, relying on the GUI builder to
generate the window system code required to implement the user interface
specified by the programmer and requiring the programmer to code only the
application functionality. As with the direct coding approach, the
applications code is often integrated with the GUI in the same program.
<P>
Recently a third approach has been used. This employs a high-level,
interpreted language in which the programmer codes all or part of the
application, with at least the GUI being implemented in the high-level
interpreted language. Tcl/Tk is a recent example of this approach. Other
examples of the high-level interpreted approach from outside the Unix/X
world include Apple's HyperCard/HyperTalk, and the Visual Basic facility of
Microsoft Windows.
<P>
This paper presents a new, high-level, interpreted window system toolkit
which like Tcl/Tk is also based on the Tcl interpreter. Unlike Tcl/Tk,
which is by definition Tk specific, our approach tries to maximize window
system and window system toolkit independence to ease future upgrades to new
window systems or toolkits. The initial implementation, which is for the X
Window System, is based on the X Toolkit (a part of the X Consortium X11
release) and uses standard Xt-based widgets. Support for an asynchronous,
event-driven messaging system is an integral part of the design, allowing
the GUI to be isolated from the functional part of an application and making
the facility well suited to distributed applications, e.g., where a GUI
executing locally talks to application code executing remotely, with the
application downloading the GUI to be run at startup time. The core
facility is implemented as a simple C-callable library which can be used to
implement new GUI-based programs without having to write any window
system-level code.
<P>
An important aspect of the facility described in this paper is that it
represents a general user interface management system (UIMS) tailored for
astronomical GUIs. The intent is that by providing a high-level facility
tailored for our applications, we can simplify the task of developing GUIs
for astronomical applications while providing a greater degree of
consistency between applications since they will share the same GUI
components. This is particularly important in the area of 2D graphics and
imaging, including presentation and user interaction with such data, since
the standard toolkits do not address this area.
<P>
<H1><A NAME=SECTION021920000000000000000> The Widget Server</A></H1>
<P>
<H2><A NAME=SECTION021921000000000000000> Overview</A></H2>
<P>
``Widgets'' (window objects), are the basic building blocks of graphical user
interfaces. A window system toolkit provides a selection of widgets that
the programmer can use to construct a user interface. Typical widgets
include things like push buttons, scrollbars, pop-down menus, or scrolling
text regions. The <i> widget server</i> serves up widgets to a remote client
process in much the same way that the X display server serves up windows and
other low-level display resources to a remote client application.
<P>
When a client application starts up it connects to the widget server and
downloads its GUI. The GUI is a simple block of text which is interpreted
and executed by the widget server. The GUI text contains a description of
the widgets comprising the user interface, a number of interpreted action
procedures to be called to process user interface or client events during
execution, and any code needed to initialize the GUI.
During execution the client application waits for and executes requests from
the GUI, and sends messages to the GUI to inform it of any ``client events,''
or changes in the state of the client. The conventional compiled client
application implements all the application-specific functionality, but does
not communicate directly with the user.
<P>
To the client application the GUI is merely a block of text to be passed on
to the widget server; the client code knows nothing about the GUI other than
the name of the GUI file to be sent to the widget server. The client knows
only about the applications functionality which it implements, and the
messages and requests used to communicate with the GUI. The GUI is
completely isolated from the client application. While to the user the GUI
appears to be an integral part of the application, the actual compiled
client application has an interpreted command-line interface and can be
executed stand-alone without any GUI.
<P>
<H2><A NAME=SECTION021922000000000000000> Widget Server Architecture</A></H2>
<P>
<P><A NAME=1250> </A><A NAME=todyfig1> </A><IMG ALIGN=BOTTOM ALT="" SRC="/iraf/web/projects/x11iraf/docs/todyd1.gif">
<BR><STRONG>Figure:</STRONG> Widget Server Architecture.
<A HREF="http://hoth.stsci.edu/adass-figs/todyd1.eps">
Original PostScript figure (34 kB)
</A><P>
<BR>
<P>
<P>
The architecture of an application which uses the widget server is
summarized in Figure <A HREF="todyd.html#todyfig1">1</A>.
The typical widget server-based application consists of two processes, the
process containing the client application, and the widget server process
itself which executes the client's GUI. All user interface functionality
resides in the GUI and all application-specific functionality resides in
the client. During execution these processes communicate via an
asynchronous object-based messaging system.
<P>
<H2><A NAME=SECTION021923000000000000000> Advantages of the Widget Server</A></H2>
<P>
The widget server architecture separates the user interface from the
application-specific code and provides a high-level interpreted language
for developing GUIs. This approach has significant advantages,
including the following:
<P>
<OL><LI>
The high-level, interpreted nature of the widget server makes it much
easier to develop GUIs than is the case with toolkit-level programming or
the conventional, compile-link approach.
<LI>
The use of an interpreted runtime language (Tcl) to compose the GUI is more
powerful than the visual programming approach used in GUI builders, since
the latter only address the appearance of the user interface.
User interface builders can still be used with the widget server to
interactively layout the user interface, although this is less important
than it might be given the interpreted nature of the GUI (i.e., changes can be
made and the GUI redisplayed very quickly).
<LI>
The high-level, integrated nature of the widget server-based GUI development
environment makes it straightforward to customize the environment to support
a particular class of application. This is important for large systems
where GUIs are developed by many people working independently,
to reduce the overall effort and improve consistency.
<LI>
The widget server isolates all window system and toolkit code into a single
executable which can serve any number of applications. This greatly reduces
disk space consumption in a large system that has many application GUIs.
<LI>
Since the widget server is a single executable it is easy to have multiple
versions, e.g., supporting different toolkits or incorporating proprietary
software to optimize performance for a particular class of workstation.
<LI>
Since all the window system code is isolated into a separate process the
client application is completely window system independent, allowing the
same client application to be used with a widget server GUI executing on
any local or remote platform running any operating system.
<LI>
Porting a whole system full of GUIs to a new platform can be done by a
single individual since only the widget server itself need be ported.
<LI>
No window system libraries, and indeed no compilation, is needed
to develop GUIs. All that is needed is the widget server executable.
This makes it much more feasible to use commercial or platform specific
libraries should this be desired.
<LI>
The GUI is completely isolated into a small text file separate from the
application, allowing the GUI and the application to be developed separately,
or several alternate GUIs to be used with a single application.
<LI>
The widget server is well suited to distributed applications since the
widget server can be run on the local workstation while the client
application executes remotely. This allows the entire GUI to execute
interactively on the local workstation, a much more efficient approach than,
for example, running an X application over the network.
</OL>
<P>
Possible disadvantages of the widget server approach are its relative
complexity and the possibility of inefficiency when the application is
distributed over two or more processes. For a small system where only a few
GUI-based applications are needed many of our big-system concerns are
unimportant and it might be simpler to program directly at the toolkit
level, especially if a user interface builder tool is available. Efficiency
can be a problem if the client code is required to respond in real time to
user interface events, however this is rarely a problem in well designed
applications since the more interactive portions of the program can be moved
into the GUI, implemented as interpreted GUI procedures or as calls to the
compiled functions in the widget server itself. The asynchronous nature of
the messaging system ensures that the user interface will always be
responsive even when the client is busy computing.
<P>
<P><A NAME=1259> </A><A NAME=todyfig2> </A><IMG ALIGN=BOTTOM ALT="" SRC="/iraf/web/projects/x11iraf/docs/todyd2.gif">
<BR><STRONG>Figure 2:</STRONG> A Simple GUI: The ``Hello, world'' Application<BR>
<P><H2><A NAME=SECTION021924000000000000000> Platform Independence</A></H2>
<P>
The widget server automatically provides a high degree of platform and
window system independence since the GUI is isolated from the client
application; in the worst case only the GUI file has to be changed to use a
GUI-based application on a new platform. The current implementation
provides full platform independence for platforms which run the X Window
System since the current widget server implementation is X-based. No
changes to the GUI files are needed for these platforms.
<P>
The current widget server implementation does not, however, provide full
window system toolkit independence for window systems other than X. Ideally
the widget server should define a virtual set of widgets which can be
implemented on a variety of window systems and window system toolkits; not
only X but also Windows, Windows NT, Macintosh, etc. This problem has
partially been solved in that the language used in widget server GUIs
isolates the widget-dependent code into a portion of the GUI which describes
the widget hierarchy, assigning widget classes to named GUI objects. The
runtime part of the GUI, i.e., the interpreted action or callback procedures
called at runtime as the GUI executes, is already almost completely widget-
and toolkit-independent. Defining a fully toolkit-independent virtual
widget set is a future problem which cannot be attempted until we have a
better idea what widgets are needed for our applications. Several
commercial window system toolkits or GUI development environments exist
which have already attempted to address this problem, at least for the
standard toolkits.
<P>
The portion of the widget server which interfaces to the underlying window
system and window system toolkit (widget set) is the <i> Object Manager</i>.
This is discussed in the next section.
<P>
<H1><A NAME=SECTION021930000000000000000> The Object Manager Library</A></H1>
<P>
<H2><A NAME=SECTION021931000000000000000> Overview</A></H2>
<P>
The widget server is actually just a shell around the Object Manager library
(OBM). The widget server extends the Object Manager by providing a way for
external clients to connect to the Object Manager to download and execute a
GUI. All of the real work of creating and executing the GUI is done by the
Object Manager library. The widget server adds a client-server communications
method.
<P>
The Object Manager provides services for creating, deactivating,
reactivating, or destroying a GUI, creating or destroying objects, and
delivering messages and events to objects within the GUI. The OBM provides
the framework within which GUIs execute, including the interpreter,
automatic memory allocation, and a library of runtime services.
The Object Manager defines four main classes of objects: <i> Server</i>,
<i> Client</i>, <i> Parameter</i> (for client events), and <i> Widget</i>, for
the graphical elements of the interface. Within the Widget class are many
subclasses, one for each type of widget.
All Object Manager execution is event driven and asynchronous and is based
on messages (requests), callbacks, and events. For example, defining a new
GUI is done by sending a message to the server object.
<P>
The set of widgets implemented by the Object Manager is not fixed, i.e., new
widgets can be added or existing widgets removed to meet the requirements of
the applications which will be using the widget server. The base Widget
class provides a generic set of methods usable with all widget subclasses.
Complex widgets subclass the base Widget class to add their own methods.
The current Object Manager provides a mixture of Xt-based widgets which
provide a Motif-like appearance but which are publically available and
redistributable. Source for these widgets and for all code used in the
widget server is included in the distribution. The current widget set
includes the base Xt widgets, the 3D Athena widgets, selected FWF (Free
Widget Foundation) widgets, plus a few others such as the Layout widget from
MIT, the HTML hypertext markup language widget from NCSA <i> Mosaic</i>, and
the gterm-image widget from the IRAF project. Additional Xt-based widgets
(including Motif, OLIT, and commercial widgets) can easily be added.
<P>
<H2><A NAME=SECTION021932000000000000000> The OBM Library</A></H2>
<P>
The main entry points of the OBM library are shown in Figure <A HREF="todyd.html#todyfig3">3</A>.
The library is very simple since everything complicated is done by the
interpreted GUI code. The main runtime function of the OBM library, from
the point of view of the application which uses the library, is messaging.
A window system application (such as the widget server) calls
<i> ObmDeliverMsg</i> to deliver a message from the client application to a
GUI object. A callback function is registered with the Object Manager to
intercept client requests and pass them on to the client.
<P>
<P><A NAME=7268> </A><A NAME=todyfig3> </A><IMG ALIGN=BOTTOM ALT="" SRC="/iraf/web/projects/x11iraf/docs/todyd3.gif">
<BR><STRONG>Figure 3:</STRONG> Principal routines of the Object Manager library, <i> libobm.a</i><BR>
<P><H2><A NAME=SECTION021933000000000000000> Using the OBM Library to Build Standalone Applications</A></H2>
<P>
Our discussion has thus far concentrated on the widget server and
distributed applications, because the widget server provides the best
architecture for adding GUIs to tasks in an existing, large data processing
system. Another important class of applications are window system
applications, where the focus is on the window system functionality
implemented by the application. Most conventional X window system
applications fall into this class.
<P>
An important use of the Object Manager library is to implement such
applications. A stand-alone, single-process window system application can be
built using the OBM library. In this case the ``client'' is not a separate
process, but an application-specific interpreter within the same process as
the OBM library. The program could be written as a conventional window
system program making direct calls to the underlying window system toolkit,
but by using the OBM library virtually all window system specific code is
eliminated and the GUI is isolated to a high-level, interpreted GUI file.
The only compiled code required is that which implements the functionality
of the application itself. The resulting task is almost completely window
system independent.
<P>
A good example of an existing stand-alone window system task built around
the OBM library is <i> ximtool</i>, the IRAF image display server program.
This is a stand-alone X window system application used for image display and
image interaction. <i> Ximtool</i> contains only about one page of C code
which has anything to do with X. All of the remaining C code handles window
system-independent raster image processing and the fifo or socket-based
binary protocol used to communicate with remote clients for image display.
The <i> ximtool</i> GUI is an interpreted GUI text file, identical to what
one might use with a widget server-based task. The widget server itself,
of course, is another example of a stand-alone X application based on the
OBM library.
<P>
<H2><A NAME=SECTION021934000000000000000> The Object Manager Shell</A></H2>
<P>
Another stand-alone host application built around the Object Manager library
is <i> obmsh</i>, the Object Manager shell. This is a Unix shell which executes
OBM windowing scripts. It can be used to execute GUI files from the Unix
command line, or be used in OBM-based scripts to write stand-alone Unix
shell scripts that can be called as commands from the Unix environment.
For example, the ``hello, world'' GUI shown in Figure <A HREF="todyd.html#todyfig2">2</A> could be
converted to a Unix command <i> hello</i> by changing the file name to ``hello''
and adding something like ``<code>SPM_quot</code>#!/usr/local/bin/obmsh"'' to the file header.
<P>
<H1><A NAME=SECTION021940000000000000000> Messaging</A></H1>
<P>
<H2><A NAME=SECTION021941000000000000000> Messaging Fundamentals</A></H2>
<P>
The key to isolating the GUI from the client code of an application, while
providing a tightly integrated, efficient application, lies with messaging.
The messaging scheme used determines how objects within the application
interact with each other during execution. This includes the interaction
of the client code (client object) with the GUI. Our discussion here will
concentrate on how messaging is used to link the client to the GUI, but it
should be noted that the same messaging scheme is used for all object-to-object
communications within the GUI as well.
<P>
Messaging as defined by the OBM consists of two parts: requests and
client events. Requests are commands send to the client (or any other
object). The recipient is free to modify or ignore the request as it wishes.
Client events are messages sent to the GUI when the client state
changes in any way. The same mechanism is also used to deliver other forms
of client information to the GUI, e.g., in response to requests. The GUI is
free to ignore client events. It is not unusual for a given GUI to be
interested in only a portion of the client events generated by a client.
<P>
A client event is a message sent to an object of the OBM class <i> Parameter</i>.
A parameter object is very simple, consisting of a name and a string value.
The GUI registers callbacks with the user interface (UI) parameters, i.e.,
client events,
that it wishes to know about. The string value of a UI parameter can be
anything, for example a number, a structure, a list, or a large block of text.
It is common for multiple callbacks to be registered on a single UI parameter
by independent elements of the GUI.
<P>
Messaging is fully asynchronous. Both requests and client events are queued
and buffered, and periodically flushed to the process on the other end.
Synchronization occurs automatically when the client waits for input from
the server (GUI). The GUI never waits for a request to complete, nor does
it check to see that a request has been honored. Rather, when the client
processes the request it sends client events back to the GUI to inform the
GUI of any actions performed by the client. The same thing happens when
the client performs actions for any other reason, hence the GUI always
reflects the true state of the client.
<P>
Client events are an important abstraction mechanism. Client events and
messages allow the client to provide the GUI with all the information it
needs to function, without the client code having any knowledge of the
nature of the user interface. Yet, since requests and client events are
decoupled, the client will function even if the client events and messages
it sends are discarded, as when running the client code without a GUI or
with radically different GUIs.
<P>
<H2><A NAME=SECTION021942000000000000000> Simple Messaging Example</A></H2>
<P>
Messaging is one of those things which is fundamentally simple, yet
surprisingly hard to explain. As a simple example, consider what happens
when the user selects a frame to be displayed in <i> ximtool</i>:
<P>
<OL><LI>
The user pushes the next frame button.
<LI>
The callback procedure (in the GUI) for the nextFrame button sends the
command ``nextFrame'' to the client.
<LI>
The client receives and processes the request, changing the frame,
sending the new frame number to the UI parameter ``frame''.
<LI>
A GUI callback procedure registered on the ``frame'' parameter is called,
updating the GUI to indicate the new display frame number.
</OL>
<P>
This example simplifies things considerably but is accurate so far as it
goes. In the real program there are a number of different ways the frame
can be changed, e.g., by the next frame or previous frame buttons, by menu
selection, keyboard accelerators, the blink timer, IRAF running in another
process, and so on. All of these end up sending a request to the <i>
ximtool</i> client which directly or indirectly results in a frame change.
When the display frame is changed a number of client events are generated to
inform the GUI not only of the new frame number, but also the new frame
title, zoom, pan, and frame flip values, type of enhancement used for the
frame, and so on. Each of these items represents a separate client event.
Although the action of the program may be arbitrarily complex in real world
examples, the basic messaging mechanism on which this is all based remains
very simple.
<P>
<H1><A NAME=SECTION021950000000000000000> Software Products</A></H1>
<P>
<H2><A NAME=SECTION021951000000000000000> The X11IRAF Package</A></H2>
<P>
All of the software described in this paper is packaged in a single
distribution called <i> x11iraf</i>. This includes <i> xgterm</i>, <i> ximtool</i>,
the Object Manager library, sources for all the third party widgets used in
OBM, and assorted demo applications. Everything needed to build the package
is included, including compatible versions of some publically available
libraries, e.g., Tcl and Xpm. Despite the name the software is
not tied to IRAF in any way, other than that it is a product of the IRAF
project and is used for IRAF GUIs.
<P>
<H2><A NAME=SECTION021952000000000000000> Xgterm</A></H2>
<P>
<i> Xgterm</i> is an upwards compatible version of the popular <i> xterm</i>
with the <i> xterm</i> graphics ripped out and replaced with an
OBM-based GUI which uses the gterm-image widget for graphics. The
graphics supports a number of extensions, including full color support, an
integrated imaging capability, dialog interaction, intelligent unconstrained
resize, and a full crosshair cursor. Although <i> xgterm</i> is often used as
a simple terminal emulator it is also a general widget server since it
contains the full OBM library, and it can be used to execute
arbitrarily complex OBM-based GUIs and manage the communications with the
remote client. The current version of <i> xgterm</i> is based on the X11R6
version of <i> xterm</i>.
<P>
<H2><A NAME=SECTION021953000000000000000> Ximtool</A></H2>
<P>
<i> Ximtool</i> is an image display server, used by remote client applications
such as IRAF to display and interact with images. Several frames can be
loaded and independently displayed in a full-frame or tiled configuration.
Display frames can be any size. <i> Ximtool</i> is a good example of a
conventional single process windowing application which uses the OBM library
for the GUI and the window system interface.
<P>
<H2><A NAME=SECTION021954000000000000000> The Object Manager Library</A></H2>
<P>
The Object Manager library (OBM) is a high-level, interpreted window system
toolkit that is used to implement arbitrary graphics user interfaces. The OBM
library uses Tcl as the interpreter. The current version of the OBM
library is based on the X toolkit and can be used with any Xt-based
widget or widget set.
<P>
<H2><A NAME=SECTION021955000000000000000> The Gterm-Image Widget</A></H2>
<P>
The gterm-image widget is an X Toolkit-based widget for general
2D graphics and image display. This is a complex widget and a full
description of its capabilities is beyond the scope of this paper. The
Gterm widget provides a general GKS-like vector graphics and text display
capability. An integrated image display capability allows any number and
size of image rasters to be created within the widget or in the X server.
<i> Mappings</i> can be defined to map one raster to another, permitting
general graphics pipelines involving scaling and other geometric transforms
to be set up. Colormap support is included for grayscale and pseudocolor
rendering of raster data. An interactive <i> graphics marker</i> facility is
provided for interaction with the displayed graphic. The Gterm widget is
used for all graphics and imaging in <i> xgterm</i> and <i> ximtool</i>.
<P>
<H1><A NAME=SECTION021960000000000000000> Adding GUIs to IRAF Applications</A></H1>
<P>
A major application of the widget server and the other software described
in this paper is in adding GUIs to IRAF applications. In this case the
IRAF task is the client: when the IRAF task starts up it downloads its GUI
to the widget server, and during execution the IRAF task and the GUI
communicate via the messaging facility described earlier. The changes
required to add a GUI to an IRAF task are minor, ranging from
changing a single line of code to cause the GUI file to be downloaded, to
defining a set of client events and adding <i> gmsg</i> calls to allow more
complete integration of the GUI. Adding a GUI to a task increases the
system size by only the 10 Kb or so required for the GUI file.
<P>
<H1><A NAME=SECTION021970000000000000000> Availability and Further Information</A></H1>
<P>
Further information on the software described in this paper, including
more detailed documentation, full sources, and executables for a variety
of platforms can be found in
<A HREF="/iraf/web/projects/x11iraf">the X11IRAF Web page</A>.
Further information on IRAF itself and other IRAF products can be found in
<A HREF="/iraf/ftp>the IRAF anonymous ftp archives</A>.
Documentation on Tcl, Xt/XLIB and the other standard software products
used in X11IRAF is available from many sources.
<P>
<P>
<P>
<P>
<BR> <HR>
<P><ADDRESS>
adass4_editors@stsci.edu
</ADDRESS>
</BODY>
|
