 |
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass00/P3-10/
Дата изменения: Tue May 29 20:22:31 2001 Дата индексирования: Tue Oct 2 04:54:40 2012 Кодировка: Поисковые слова: star |
XImtool was originally designed using the IRAF Widget Server architecture (Tody, 1995). This provided a separation of the client application code and the user interface, either of which could be replaced or augmented with little or no change to the other. Using traditional methods, however, adding any major new functionality to the program would still likely involve substantial changes to both the client and GUI code. To solve this, XImtool has been enhanced to allow arbitrary custom components, executing as external processes, to be dynamically loaded at runtime.
New components are interfaced as named instances of the Widget Server Client class and are fully integrated into the base server using a simple text messaging scheme similar to that already used by client and GUI communications in the Widget Server. New GUI elements may be uploaded from the component and created when needed, and additional callback procedures can be defined that subscribe the component to events in the GUI (frame changes, cursor movement, etc.) to which it can react. Unlike the traditional plug-in model, the compiled portion of a component executes as an external process, allowing components to be written in any language. The main server and components communicate over an IPC socket layer which is transparent to both. Components attach themselves by requesting a connection on a dedicated socket. The module and XImtool then negotiate a private channel for communications, allowing other modules to later connect as needed.
WCSPIX, the first of these Image Support Module (ISM) components to be implemented using this new facility, provides real-time pixel value and WCS display using direct access to the actual disk image used to load the display. The module is written as an IRAF task to allow easier access to all image formats supported by the IRAF interfaces (including Mosaics), something that could not be easily done using the old architecture. Other ISM components may now be easily written to provide new functionality such as vector graphics display, network catalog access, or other image analysis. With only a minimal understanding of the XImtool GUI, users can write their own components using a standard API provided.
The basic XImtool architecture (Figure 1) is a single process in which text messages (e.g., to tell the application to change the frame, or the GUI to set the label of a button) are exchanged between the client and GUI to provide the interactivity and core functions of the task. New functionality is supplied by one or more ISM components running as a separate process and connected by text messaging over a socket layer between the component and the base server. ISM modules may send messages to the XImtool client, its GUI or other ISM modules as needed.
Widget Server messages are normally of the form " send object message". As named Client objects, messages sent to an ISM require no special formatting and are simply directed to the channel that was negotiated when the ISM first connected. The syntax and content of the message sent to a component is arbitrary and determined by the needs and abilities of the ISM itself. ISM messages sent to XImtool follow the same rule, however the message itself does require a special syntax. Namely, messages must be preceded with keyword source if the message contains GUI Tcl code to be executed (e.g., callbacks needed by the ISM, new GUI objects, etc.), alert if the message is some text to be displayed on the XImtool alert panel, or deliver if the message text should be delivered to the ISM-specific callback that was previously uploaded in a source message.
More complex components (such as the WCSPIX module described here) may also require support code in the compiled portion of XImtool. To deal with this, a list of ISM callbacks is searched when a component first connects and any registered procedures are executed. In the case of the WCSPIX module, such callbacks are executed when it first connects (to initialize the ISM with a list of the currently displayed image regions) and when it disconnects (to clean up). A more general command callback for each ISM can also be registered so that new code specific to the ISM is isolated from the core system, minimizing the impact of an upgrade or a replacement of the component at a later time. Although not implemented in this release, such compiled code could be loaded dynamically as a shared object, further isolating it from the core system.
Formatting of the messages and the details of how they are used by the transport layer are hidden in an interface on each side of the connection. A standard API to connect the component and handle messages is available to support both IRAF and other compiled tasks using a simple IRAF library or an extension to the Client Display Library (Fitzpatrick, 1998).
The Image/WCS ISM, WCSPIX, is written as a general purpose interface to all types of images supported by IRAF and provides a set of generic methods to query an image object for pixel or header data, coordinate systems available for the image (logical, world, or derivatives such as sky coordinate transformations) and translations of coordinates. It is also responsible for caching all images currently displayed in the server. The module is written to allow image objects to be subclassed using new functions to provide the actual image interaction. This means support for new formats such as Mosaics, spectral data or even tables can be added without requiring a new ISM.
The client display task defines a WCS for each region of the display frame buffer, and this information is passed to WCSPIX which initializes the object by opening the image and placing it in the cache. Cursor events in XImtool are translated to coordinates within each image region on the display, and these are then passed to the task to be translated and formatted to any of the WCS values requested by the user in the GUI. The XImtool GUI is responsible only for displaying the strings on the panel (Figure 2) and plays no direct part in the coordinate translation.
Along with the new component architecture providing real-time pixel and WCS readout, several other new features have also been added:
Fitzpatrick, M. 1998, in ASP Conf. Ser., Vol. 145, Astronomical Data Analysis Software and Systems VII, ed. R. Albrecht, R. N. Hook, & H. A. Bushouse (San Francisco: ASP), 200
Tody, D. 1995, in ASP Conf. Ser., Vol. 77, Astronomical Data Analysis Software and Systems IV, ed. R. A. Shaw, H. E. Payne, & J. J. E. Hayes (San Francisco: ASP), 89
