diff options
| author | Joseph Hunkeler <jhunkeler@gmail.com> | 2015-07-08 20:46:52 -0400 |
|---|---|---|
| committer | Joseph Hunkeler <jhunkeler@gmail.com> | 2015-07-08 20:46:52 -0400 |
| commit | fa080de7afc95aa1c19a6e6fc0e0708ced2eadc4 (patch) | |
| tree | bdda434976bc09c864f2e4fa6f16ba1952b1e555 /vendor/x11iraf/obm/docs/tody.paper | |
| download | iraf-linux-fa080de7afc95aa1c19a6e6fc0e0708ced2eadc4.tar.gz | |
Initial commit
Diffstat (limited to 'vendor/x11iraf/obm/docs/tody.paper')
| -rw-r--r-- | vendor/x11iraf/obm/docs/tody.paper/todyd.html | 522 | ||||
| -rw-r--r-- | vendor/x11iraf/obm/docs/tody.paper/todyd1.gif | bin | 0 -> 5681 bytes | |||
| -rw-r--r-- | vendor/x11iraf/obm/docs/tody.paper/todyd2.gif | bin | 0 -> 6468 bytes | |||
| -rw-r--r-- | vendor/x11iraf/obm/docs/tody.paper/todyd3.gif | bin | 0 -> 3535 bytes |
4 files changed, 522 insertions, 0 deletions
diff --git a/vendor/x11iraf/obm/docs/tody.paper/todyd.html b/vendor/x11iraf/obm/docs/tody.paper/todyd.html new file mode 100644 index 00000000..53705df4 --- /dev/null +++ b/vendor/x11iraf/obm/docs/tody.paper/todyd.html @@ -0,0 +1,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> diff --git a/vendor/x11iraf/obm/docs/tody.paper/todyd1.gif b/vendor/x11iraf/obm/docs/tody.paper/todyd1.gif Binary files differnew file mode 100644 index 00000000..ef206249 --- /dev/null +++ b/vendor/x11iraf/obm/docs/tody.paper/todyd1.gif diff --git a/vendor/x11iraf/obm/docs/tody.paper/todyd2.gif b/vendor/x11iraf/obm/docs/tody.paper/todyd2.gif Binary files differnew file mode 100644 index 00000000..b3aea8ba --- /dev/null +++ b/vendor/x11iraf/obm/docs/tody.paper/todyd2.gif diff --git a/vendor/x11iraf/obm/docs/tody.paper/todyd3.gif b/vendor/x11iraf/obm/docs/tody.paper/todyd3.gif Binary files differnew file mode 100644 index 00000000..7038a128 --- /dev/null +++ b/vendor/x11iraf/obm/docs/tody.paper/todyd3.gif |
