Configuring IDL on X Window Systems

QUESTION: Whoa! Did IDL, like, escape from Quality Control way before its time? Or did I just miss something about setting it up? Windows don't repair themselves. Colors are a disaster. Is this the way things are suppose to work on my X-Windows system!?

ANSWER: Uh, no, not exactly. What you are probably looking at are the default settings for IDL. These are, uh, not very good. What you need to do are select settings that actually work for you and your machine. Typically, IDL is configured properly in an IDL startup file that you create with a text editor and store somewhere on your computer. This is a file that is executed as a batch file when IDL starts up and before it opens any IDL graphics windows. The latter is extremely important. Once a graphics window is opened in IDL, certain selections are made that cannot be changed or reversed in the IDL session.

Setting the IDL_STARTUP Environment Variable

Environment variables are generally specified in a file that is read by your shell program at startup. Syntax varies depending upon the specific shell you are using. Here are some examples for the C shell (csh) and the Bourne shell (sh).

Assume I have a startup file named "dave_startup.pro" and I have placed the file in /usr/local/david.

C Shell Syntax

    setenv IDL_STARTUP /usr/local/david/dave_startup.pro

Bourne Shell Syntax

    IDL_STARTUP="/usr/local/david/dave_startup.pro"
    export IDL_STARTUP

If you are working in the IDL Workbench, in IDL 7 or higher, you can set the IDL start-up file via the IDL Preferences dialog under the Window menu.

Setting the Proper Visual Class

The most important section of the IDL startup file should select the proper X-Window Visual Class. You will have several choices, depending on the graphics card you have available, etc., but I am going to assume you have a 24-bit graphics card. Almost everyone does these days.

First of all, find out what Visual Class you get when you start up IDL now. Start a fresh session of IDL, then type these commands:

    Window
    Device, Get_Visual_Name=theVisual, Get_Visual_Depth=theDepth
    Print, theVisual, theDepth

If the visual class name is DirectColor, your situation is hopeless. No wonder you can't figure IDL out! :-)

If the visual class name is PseudoColor, you either have an 8-bit graphics card, or you are stuck in the 1970's. If it is the former, you are fine. If it is the latter, you should know we are now in the 21st century. We have moved on. (Although there is a reasonably good chance your software hasn't and you may be stuck in the past for good reason. You will have to decide.)

If the visual class name is TRUECOLOR, you are golden. You can move on to the next section now.

If the visual class name is anything other than the names mentioned so far, you are in deep, deep trouble. I can't help you. You probably have an OS configuration problem. You might try asking for help on the IDL newsgroup.

Hopefully, you will have a depth of 24, but if it is 8, then you will have to live with a PSEUDOCOLOR visual. If you have a depth of 8 and a visual class other than PSEUDOCOLOR, contact the IDL newsgroup. We'll see if we can help. If you have an 8-bit depth and PSEUDOCOLOR visual, we feel for you, but we can't help you. Carry on.

OK, if you are still with me, you have a 24-bit depth and a visual class name of DIRECTCOLOR. You are not alone. Lot's of people are still here, unfortunately. This is because DirectColor is at a higher level than TrueColor in the X-Windows pantheon of X-Window Visuals. (It is a mystery to me why this is so, since I have never seen a machine set up correctly in DirectColor, except once, years and years ago.) But IDL, in its wisdom, always tries to give you the best of everything. So if this visual class is available, IDL selects it. In this case, getting the best is a bad idea!

To overcome IDL's natural proclivities, you must put the following line in your IDL start-up file. (The file you just set the IDL_STARTUP environment variable to point to!)

    DEVICE, TRUE_COLOR=24

If your television viewing habits tend toward “Leave it to Beaver” and the History Channel, you can put yourself into a PSEUDOCOLOR visual with the PSEUDO_COLOR keyword to the DEVICE command, but I don't recommend it unless you have excellent reason to do so. You won't be able to run much modern software, including my Catalyst Library.

Setting Up Window Repair

The next thing you might want to be concerned about is window repair. If you create a graphics window in IDL and you move another window in front of the graphics window, then remove the front window to expose the graphics window again, the graphics window should be "repaired". In other words, you should still see the graphics plot you put into the window. If you don't, if there is a blank space where the previous window was, you have "backing store" problems.

Backing store is the technical term for window repair. IDL by default asks the window manager to be responsible for backing store. Most of the time the window manager accepts this responsibility, but it doesn't have to, and many window managers (especially LINUX window managers) are configured by default not to accept this responsibility. Often, the window manager can be configured to accept this responsibility, but how you do so is outside the scope of this article.

What you should know is that if your window manager wants to shirk its responsibility for whatever reason, IDL is willing and able to shoulder the burden, but you have to tell it to. This is also done in the IDL startup file with the following command:

   DEVICE, RETAIN=2

Setting Up Color Decomposition

The next thing you need to know is that when IDL is in a 24-bit color environment it can treat a color value as a number that can be "decomposed" into three numbers representing the RGB values of a particular color, or it can treat the color value as an index into the color table, where the RGB values for the color you wish to specify can be found. We call the former the "decomposition 1" or the "decomposition ON" state. We call the latter the "decomposition 0" or the "decomposition OFF" state.

By default, IDL comes up in the "decomposition ON" state. That is, any color value is treated as though it were a number that should be decomposed into three RGB numbers to specify a particular color. This is, generally, a good thing, since you automatically have access to all 16.7 million colors your graphics card will allow. In "decomposition OFF" state you are restricted to the 256 colors currently loaded in the color table. It seems a waste of a fairly expensive 24-bit graphics card to be in this state.

Nevertheless, a LOT of software has been written before the wide availability of 24-bit color. These programs often work best (or exclusively) in color "decomposition OFF" mode. (See How Do Colors Work on a 24-Bit Display for additional information.) For this reason, a great many programmers will prefer that their IDL session start up in color "decompositon OFF" mode. (Not me. I prefer to write programs that are insensitive to the color decomposition state or mode, reasoning that if I do my programs actually have a chance of working on my client's machine. Other people prefer the pressure of a big demo in front of important people and great uncertainty about whether anything will work.) If you are one of these people, you will want to add this command to your IDL startup file:

    DEVICE, DECOMPOSED=0

That should do it. Everyone will need the first of these three commands. LINUX users in particular will probably need the second of these commands. And anyone still wearing those leisure suits with the white belts will want to add the third of these commands to their startup files.

And, of course, if you want to actually use IDL in a decent programming environment, you are going to have to install the IDLWAVE mode for EMACS.

As always, Happy Computing!

Example LINUX Start-Up File

Here is an example of an IDL startup file I use on my LINUX machine. It is set up to work with IDL 6.4 or for IDL 7.0. I use the IDL Workbench in the latter version, but I do not let the Workbench set up the IDL path for me. I do that myself in the IDL Workbench IDL Preferences dialog. I do have to set the IDL Path for IDL 6.4.

You will notice I use a slightly larger font in my IDL session. My eyes aren't what they used to be, and I find the default font in LINUX extremely small! For some reason, UNIX versions of IDL have a hard time getting it into their head that I really mean this, and often ignore my request until some random time later in the day (often after lunch), when they suddenly lurch forward and start doing what I want. I don't understand it at all. In any case, creating the window and drawing something in it is my way of getting IDL's attention.

   ; TRUE_COLOR visual class and maintain backing store for me.
   DEVICE, RETAIN=2, TRUE_COLOR=24, DECOMPOSED=1

   ; All integers at main level are LONG and enforce square bracket array subscripting.
   COMPILE_OPT idl2

   ; Set up IDL PATH for finding files, etc.
   IF Float(!Version.Release) GE 7 THEN $
   	Pref_Set, 'IDL_START_DIR', '+/home/fanning/IDL/', /COMMIT $ 
   ELSE $
      !PATH =  Expand_Path('~/IDL/coyote') + ':' + $
               Expand_Path('~/IDL/coyoteplus') + ':' + $
               Expand_Path('+~/IDL/catalyst') + ':' + $
               Expand_Path('~/IDL/idl_util') + ':' + $
               Expand_Path('+~/misr') + ':' + $            
               Expand_Path('~/IDL/idl_grids') + ':' + $
               !PATH

   ; Please, dear God, give me a font I can see!!
   DEVICE, SET_CHARACTER_SIZE=[9,12]
   Window, XSIZE=400, YSIZE=400, /PIXMAP
   Plot, Findgen(11)
   WDelete, !D.Window
   Print, 'Executed IDLSTARTUP.pro'

[Return to IDL Programming Tips]