Section 14: XGterm/XImtool ISSUES

How do I change colors (cursor, background, text, etc) in my XGterm window?

    The crosshair cursor color is set by the "crosshairCursorColor" X
resource, you would reset it by defining e.g.
    *Gterm.crosshairCursorColor:   cyan
in your .Xdefaults file.  The background and text colors are set using a
combination of X resources to set the predefined colors and an iraf environ-
ment variable to say which colors are used for text, background, axis labels,
etc.  The color resources are named 'color0' through 'color9', colors zero
and one are the background and foreground colors respectively and defaults
to white on black.  You set these resources using e.g.
    *Gterm*color0:                 darkslategrey
    *Gterm*color1:                 linen
    *Gterm*color2:                 red
    *Gterm*color3:                 green
    *Gterm*color4:                 blue
    *Gterm*color5:                 cyan
    *Gterm*color6:                 yellow
    *Gterm*color7:                 purple
    *Gterm*color8:                 magenta
    *Gterm*color9:                 slategray
The environment variable I mentioned is called 'glbcolor' and is defined in
V2.10.3 (or after) to be
        pt      - plot title
        fr      - viewport frame (the background around the plotting area)
        al      - axis labels
        tl      - tick label
        ax      - axis
        tk      - tick
        gr      - grid between tick marks
The numbers are the color indices above (i.e. "tk=5" say that the tick marks
are done in color5 (cyan)).   To make use of xgterm color graphics you
should have the following set in your or file:
        stty xgterm
Color graphics is enabled only if you are using V2.10.3BETA or a
later version of IRAF, but using X resources you can still change
the background and foreground colors when working with an earlier version
of IRAF.  Resources for the text window are the same as for xterm.

How do I change the crosshair cursor color so it appears on my mono- chrome monitor?

  The crosshair cursor color is set by the "crosshairCursorColor" X
resource, you would reset it by defining e.g.
    *Gterm.crosshairCursorColor:      white
in your .Xdefaults file.  Alternatively you can start XGterm by setting the
reource on the command line using e.g.
	% xgterm -xrm "*crosshairCursorColor:white"

How do I start XImtool with private fifo pipes?

  Ximtool running with V2.10.3 will accept a connection on a domain socket
so using private fifo pipes (e.g. for X-terminal users) is no longer the
preferred method.  For older IRAF versions provate pipes provide a backward
compatability and can still be used in the same way.  The pipes used are
defined by the 'input_fifo' and 'output_fifo' reources.   When starting
XImtool you specify the fifo's to use with something like
    % ximtool -fifo /path/imt1
The 'i' and 'o' parts of the pipe name are appended automatically.  You can
tell IRAF where the private fifos are by defining the IMTDEV unix environment
variable as
	setenv IMTDEV  fifo:/path/imt1i:/path/imt1o
before starting the CL.

How should I set up my users to run Ximtool on an X-terminal?

  X-terminal users (or others who are running XImtool on a server) will want
to disable the fifo pipes and the tcp/ip port so that only the unix domain
sockets are used (otherwise another user displaying to the /dev fifo pipes
may have their image appear on your screen since XImtool will still read
the pipes).  The fifo pipes are disabled by setting the "input_fifo" XImtool
resource to "none", tcp/ip sockets are disabled by betting the "port" re-
source to zero.  This can be done on the command line using e.g.
        % ximtool -xrm "*input_fifo:none" -xrm "*port:0"
This command can easily be aliased but the X resources can also be per-
manently set by adding the following lines to your .Xdefaults file:
        XImtool*port:           0
        XImtool*input_fifo:     none
These values will take effect the next time the window system is started
or can be loaded immediately using the command
        % xrdb -load ~/.Xdefaults
XImtool can then be started without any command line arguments and only
the domain socket will be used.  These are created automatically and will
be unique for each user so conflicts are avoided.

Can I control more than one XImtool at the same time?

   Yes, but controlling them from the same IRAF session is complicated.
Since XImtool can accept two inputs simultaneously and has multiple
frame buffers users should consider whether they really need two XImtools
in the first place.  If so then the easiest way is to control them from
different IRAF sessions so that different socket numbers can be assigned
to each session, each XImtool would be started with a different socket
number as well.  For example, in the first XGterm window you would define
the socket and start XImtool using
      % setenv IMTDEV         unix:/u2/smith/iraf/dev/IMT1%d
      % ximtool -xrm "*input_fifo:none" -xrm "*port:0" \
                -xrm "*unixaddr:/u2/smith/iraf/dev/IMT1%d" &
In a second XGterm window you change the socket number slightly and start
things using
      % setenv IMTDEV         unix:/u2/smith/iraf/dev/IMT2%d
      % ximtool -xrm "*input_fifo:none" -xrm "*port:0" \
                -xrm "*unixaddr:/u2/smith/iraf/dev/IMT2%d" &
Each IRAF session will write to a different socket, and each XImtool will
be listening on a different socket.  It should be noted that something
similar can also be done using either fifos or tcp/ip sockets for the

How can I change the background color in my ximtool window - the default color is black - I want white?

   The image display window in XImtool is nothing more than a GTerm widget
so the trick is to simply change the background and foreground colors.  A
"reverse video" option may be included in a later release to simplify this,
for now defining the following resources in your .Xdefaults file should
        XImtool*imagewin.color0: white
        XImtool*imagewin.color1: black
These may also be specified on the command line using
    % ximtool -xrm "*imagewin.color0:white" -xrm "*imagewin.color1: black"
[NOTE for SAOtng Users:  resource settings for SAOtng should be specified
as e.g. "*color0" instead of "*imagewin.color0" due to small differences
in the code.]

Can I set the size and placement of the xgterm graphics window at startup time?

   As with GTerm the graphics window geometry can be specified with the
"-G" or "%geom" flag on the command line, for instance
        % xgterm -G 1100x350+10-10       # or alternatively
        % xgterm %1100x350+10-10
will produce a wide rectangular window in the lower portion of the screen
suitable for examining spectra.  The geometry may also be specified in the
user's .Xdefaults file by specifying
        XGterm*tekGeometry:             1100x350+10-10

Can I set the size and placement of the ximtool window at startup time?

   To reset the geometry of the XImtool window itself use something like
        % ximtool -xrm "*imagewin.height:800" -xrm "*imagewin.width:600"
or in your .Xdefaults file put
	XImtool*imagewin.width:		600
	XImtool*imagewin.height:	800

How can I tell what the default resources are for xgterm and ximtool? Is there a file somewhere with these values in them?

      A full listing of resources is available in the man pages distributed
with X11IRAF.  For XImtool, the Gterm widget (used for the display) resources
and described fully in the XGterm man page.   If the manual pages for
X11IRAF tasks were not installed on your system they are available in
PostScript form from the /iraf/x11iraf directory in our archive along with
the main X11IRAF distribution files.

Can FOCAS make use of the socket connections in XImtool for image display?

	Yes, as long as it was compiled against a V2.10.3 or later system.
Users may be familiar with setting the FOCASPIPE environment variable to
define a personal fifo pipe to be used instead of the default /dev/imt*
pipes, internally this pipe specification is turned into the same
"fifo:<input_fifo>:<output_fifo>" syntax used when defining the IMTDEV
environment variable.  This means that if FOCASPIPE is an empty string,
i.e. it's defined simply with
	% setenv FOCASPIPE
the display code uses the same heuristic to determine the connection type
(looks for IMTDEV specification and if not found attempts to use the
default unix domain socket) as a normal IRAF display command, so with
this definition and using XImtool as a display server there is no need
to use private fifos with FOCAS.  This also means that in this case IMTDEV
can still be used to define the connection type, what's not obvious is
that it's also possible to set FOCASPIPE as you would IMTDEV to specify
the protocol.  For example, the following are equivalent to display to
a remote XImtool running on node
	% setenv IMTDEV
	% setenv FOCASPIPE
	% fdisplay
	% setenv FOCASPIPE
	% fdisplay

When I try to start up XImtool I get an error about a BadMatch.

        The BadMatch means that your X server is using something other than
an 8-bit PseudoColor default visual.  Unfortunately the only workaround for
this is to start an 8-bit server using a command such as 

        % startx -- -bpp 8
        % startx -- -depth 8    (for XFree86 V4 systems like RedHat 7)

(note the command will vary depending on the platform).

For PC systems using XFree86:

If you don't have an 8-bit visual defined the Xconfigurator command will let
you set one up.  You can switch back to 24-bits when you don't need ximtool.
If you don't want to log out of X to switch there is another more complicated
way, see

This starts another X server on an alternate virtual console, it takes a
bit more memory but works like another virtual desktop.         
Another workaround is to use VNC, see details at

For most other systems:

        Lastly,  the successor to SAOtng (which is based on XImtool) is
called DS9 and work was recently completed to add the IIS display protocol
to it so it can be used as an image display server for IRAF, and DS9 will
work in 24-bit visuals.  For more information about this or to get the
program see

or contact  

They also have a web page with more information at

Here are some additional details:

When XImtool was first written, about 5-6 years ago, 24-bit displays were
still only available on high end systems or specialized platforms such as
SGI, most PCs in the world also lacked the video cards for 24-bit and
Linux was still in it's early stages.  Nowadays it's hard to buy a new
system that doesn't have 24-bit support.  It was always thought that
24-bit support would be added but it wasn't deemed a priority at the
beginning when the Gterm widget was being written.

The problem is not that it's difficult to display an image on a 24-bit
screen, it's that unlike programs such as XV (which display a static
image), Ximtool has too allow brightness/contrast stretching when viewing
the image.  This is currently done, for speed reasons, by recomputing and
rewriting the colormap used to display the image (rather than redisplaying
the image itself).  However, in a 24-bit display there is no colormap so
modifying the image to increase the contrast becomes non-trivial and more
expensive.  There are plans to make XImtool and the Gterm widget on
which it relies work under a 24-bit display, this will be part of an
upcoming X11IRAF release,but we cannot give you a date for when this will be

About how much disk space is needed to install 2.11 for Sun machines.

   It depends on whether you install only one or both the SunOS and
Solaris architectures.  The breakdown is roughly
    as.ssol.gen.Z      70Mb     "all sources" compressed tar file
    ib.sos4.sun.Z      21Mb     CORE system binaries for SunOS
    ib.ssol.sun.Z      35Mb     CORE system binaries for Solaris
    nb.sos4.sun.Z      15Mb     NOAO package binaries for SunOS
    nb.ssol.sun.Z      21Mb     NOAO package binaries for SunOS
You'll also need room for external packages, but you can recover ~50Mb
by stripping the iraf sources once installed, external packages can
also be stripped.

After upgrading to V2.11 external package tasks no longer recognize my images.

   In V2.11 the OIF image format was changed to make it machine independent
and to increase the size of the pixfile pathname.  In order to read this new
format all external packages or local IMFORT tasks *must* be relinked against
V2.11 to be able to read the new format.  V2.11 can still read the old format,
and where required you can force IRAF to write the old format by doing
	cl> reset oifversion = 1
before creating new images.