Steps toward removing viewer
glish
November 2004 David
King
Re-creating
the aips++ viewer without glish is a large task, as we all know.
I think it makes sense to idenfity the various tasks and come up with
an order for tackling them.
As I see it, a first major milestone to work toward is the creation of
a barebones standalone glishless
viewer, with approximate capabilities only of the current quickviewer. (To try the
quickviewer, type 'aqview <filename>' in a window initialized for
aips++). This provides a raster display of a single image file,
with default labelling, colormap, and coordinate axes. There are
fixed mouse buttons for zoom and colormap fiddling, a slider for
channel number selection, and a position tracking display.
From there, additional capabilities should be prioritized (with
SSG/NAUG input) and added. Farther below is a list of the major
additional capabilities that I am aware of.
Getting to the barebones stage involves:
- choosing a widgetset
that can be driven from C++. Modern ones such as Qt have
important development aids, such as python bindings and wysiwyg
designers. However...
- If this widgetset does not allow communication with
lower-lexel X11 directly, the graphics
platform-dependent code will have to be reimplemented.
This includes the PixelCanvas
(about 150 abstract methods), its color
tables and draw caching.
This is a non-trivial task, that should be avoided if possible.
While I would prefer to work with the Qt
widgetset, I intend to research GTK
(and Tcl/Tk) as well; we
should probably stick with a widgetset that will allow us to continue
talking raw X with the canvas.
In the meantime, I must plan a
functional interface for viewer
capabilities (based on the old glish one; hopefully simpler), and also
learn the new framework,
i.e., how these functions and their parameters (particularly the
record data) are to be sent through it.
Also in the meantime, I think
we should keep an eye on RVS,
and stay in touch with our Aussie colleagues in this area. It is
not too late to hedge our bets in this area, although that window will
close as we invest more effort in C++ gui development. Pros and
cons of RVS as I see it now:
Cons:
- The extra overhead in sending Pixelcanvas drawing commands
via CORBA leads to efficiency problems that may be unacceptable in some
cases, and is in any case unnecessary for our purposes (Anil tends to
agree here, I think).
- NRAO is not in charge of this code; we may not have the
control we (or management) feels is necessary.
- Anil is not sure how exactly how far to take this
paradigm, or where he wants to go with it. (He is giving it
thought, and has promised to put some of his ideas in writing soon).
Pros:
- It's not bad,
speed-wise. His latest single-laptop demo at ADASS was pretty
good (1-3 sec. for large image refresh).
- This is something of a side issue, but useful to note: RVS
is the only current working demonstration of glishless use of the
Display Library. It's nice to have the example, at least.
- Important: We're more likely to be able to leverage the
Aussies efforts, if they do decide to put significant effort into
RVS. If we develop in an unrelated widgetset that they're not
interested in, we're more likely to simply duplicate effort.
So... Again, I think the best
plan for the present is to stay in touch with developments and get to
the point where we can evaluate both client and server in RVS.
Meanwhile, however, I think we should proceed with prototyping a
barebones viewer in a C++ widgetset.
Additional major viewer Functionality --
going beyond 'barebones'
It's important to realize that most of these current viewer
capabilities correspond to separate sections of glish code, and will of
course require recoding in a new system as well.
- Creation and support of the flexible
option parameter ('Adjust') guis
from DDs'
parameter records. Communicating these options is complex,
including special cases for regions,
masks, colormaps, beams, colorwedges, and min/max histograms.
- File selection
and DD type gui. The viewer maintains a list of
available DD types and the data types for which they can be used, and
puts data into proper form for the DD. In addition to file names,
several types of aips++ tools
may be given, including image, measurement set, array, and sky catalog.
- Display
panel functionality surrounding the canvas:
- animation gui
(with
current state), including frame rate
timing, blink mode, response
to both user and library input.
- menus for registration of multiple DDs (and maintenance of DD
creation/registration state)
- menus for auxiliary window display, including multiple display panels
- Maintenance of special panels/DDs for color wedges (fairly involved:
creating removing panels, forwarding options from parent DD, etc.).
- Maintenance of special DDs for beam ellipses and region drawing
- annotations
(gui and panel DD management).
- mouse tool
gui: button
assignment, [de]activation of
corresponding mouse tools. Maintenance of this state.
- Print
dialog window: glish code for printing involves
creating a
Postscript canvas and reproducing the state of the displayed canvas on
it (animation, zoom, DD registration), before releasing it to draw the
postscript.
- Other display panel
functions and state (currently in a separate window): margins, multiple canvases per display
panel, number of colors in colormaps,
background color
- standard functions needed for most or all gui windows,
including
[un]map, done, and enable/disable of response to widget action and
glish
(framework) events; also (importantly) hold/release
of refresh on DL canvas(es).
- some separate glish code is used for creating sky catalogs.
- Image
Analysis and related image
applications:
- spectral
profile
display in separate, custom
viewer panels.
- image statistics and histograms
- visual region
drawing and management. This interfaces with with non-viewer code as
well.
- Fitting component lists
to images (imagefitter.g, et. al.)
- Fitting gaussians
to image profiles
(imageprofilefitter.g, et. al.)
- slice plots
- Other applications which
embed the viewer, used for imaging,
include:
- Specifying boxes for interactive
clean (interactivemask.g).
- msplot
This is
probably a good place to mention that its msplot's still-used plot mode
(along
with many other applications)
make use of the glishtk pgplot widget.
While not a viewer
application, the pgplot widget was built similarly
to the display library (i.e., its canvas widget), and presents similar
problems of conversion. As with the display library, it attaches
itself to the glishtk widgetserver process, essentially becoming part
of that service. It allows glish scripts to embed the widget in
higher-level pgplot 'tools' or other plot windows, and to control the
widget via pgplot commands sent over the glish-bus
'framework'. As with the viewer, pgplot use in a new
framework would be confined to the process where its guis are built,
not available across the framework.
Dependencies
on external glish code / services. The viewer will still
want to call many of these across a new framework.
- autogui.g, guientry.g histogramgui.g for Adjust panel
creation,
min/max histogram, etc.
- Logging (errors and other
messages--note.g, et. al.)
- Determining file types, other file
services (os.g)
- help services (help.g, bug.g, about.g,
popuphelp.g, et. al.)
- Saving/restoring options settings
(inputsmanager.g)
- Image and image analysis servers (for
visual image analysis --
image.g, imageviewersupport.g, et. al).
- imagetemporary.g, to give pure image
tools (or FITS, miriad
formats) a temporary home as an aips++ image file, as the viewer
requires.
- quanta.g (for things like beam ellipse
positioning)
- aipsrc.g (for user .aipsrc settings)
- servers.g (to start servers like
app_image)
- catalog.g (for file type identification)
- timer.g (for animation timing)
- printer.g (for secondary generic aips++
print dialog).
- along with other apps, some viewer
functions (e.g. minmax
histograms) rely on the pgplot widget.