DNA Workbench for X-windows

David Mathog mathog at seqvax.caltech.edu
Mon Nov 7 15:02:00 EST 1994

In article <39b2rt$sie at netnews.upenn.edu>, tisdall at amalthea.humgen.upenn.edu (James Tisdall) writes...
>It will be based on
>the new version 5 of the "perl" language, that includes a "Tk extension".

Looking the gift horse straight in the mouth...

Speaking as a harried system(s) manager, would all you developers please make
a real effort to not develop on top of layer after layer of semiportable
software?  I get really tired of having to install 2, 3, or 4 pieces of 
software just to get the desired program running.  More often than not, 
the requisite version of one of the support packages won't work on one
platform or another (yes, especially VMS).  

I suggest that grant reviewers going through applications that include
software development, make sure that the project employs the rules that are
put forth below.  It will save us all some money and insure that any tools
developed are available to the largest number of users. 

Portable software, which is relatively ulcer free in terms of installation
and porting, adheres to the following guidelines:

 1.  It is written in ANSI C or Fortran 77 (but NOT both).

 2.  If it has an X11 GUI interface, it should only require Xt.  If that is
     insufficient, include Xmu.  If that won't cut it, use Motif in preference 
     to SunView or even Xaw.  Yeah, Motif costs money, but it comes 
     standard on most machines, the vendors support it, and it can be
     obtained for any X11 based platform.  Conversely, SunView is is not
     often available on platforms other than Suns, and the support for Xaw
     is a bit spotty too.

     For graphics intensive applications like protein modeling, be *real*
     sure that there is no other way before committing to OpenGL.

     If at all possible, write the GUI section so that X11 can be ripped 
     out and Windows, Mac, or whatever, calls substituted instead.  

 3.  File and directory specifications are different on
     each OS, so all filename manipulations go in ONE place so that the
     appropriate OS operations can be #ifdef'd in.  NEVER assume that
     if "name" is valid, "name.out" will also be valid!!!

 4.  Simlarly, don't require that stdin and stdout be redirected on the
     command line.  Always provide some way to change these via specific
     command line options or configuration files (for OS's without command 

 5.  Make any hardware assumptions explicit and stick them in ONE
     platform.h file.  

 6.  A GUI should not freak if it expects 8 bit color but finds 24 bit or 
     black and white.  If it can't handle what it finds, put an 
     intelligible error message somewhere, and then quit.

 7.  A GUI must be able to handle 1,2, or 3 button mice.  Optimally, use
     only one button.  (Ever try getting "ALT-CTRL-Right Button" in MacX?)

 8.  The software must not require any other software to run, besides the 
     OS, of course, and possibly the appropriate layered GUI.  If absolutely
     necessary, the GUI rule can be relaxed slightly to include one 
     additional package (like Tk, or Vibrant), but ONLY if it has already 
     been verified that this extra package DOES run on all the desired
     target platforms. (This rule does not apply to modules that are 
     intended to be added to an existing package, such as GCG.)

 9.  In case sensitive languages, never distinguish between variables by
     case.  Avoid using "oh" and "zero", "el" and "one" in situations where
     they can be confused.  This makes it much easier for people 
     other than the author to port or support the software.

10.  Provide adequate documentation in (at least) Text and PostScript.
     (But not PostScript without Text - there is often no way to read it on
     line).  A set of "man" pages is no substitute for a decent manual.
     As part of the documentation, always distribute example input and output
     files so  that others can verify that the program is working properly
     on their platform. 

>There are plans afoot to make Tk work on macs and on IBM pc's with windows -
>that will probably take awhile to be accomplished, but is one reason I'm
>using the language(s) that I'm using.  (Also, perl and tk are free and have
>large and growing followings.)

If you want GUI portability now, go with the NCBI's Vibrant or use a
commercial package (of which there are several).  Vibrant is free, at least
on noncommercial software, runs on those platforms now, and you've already
paid for it with your tax dollars. 

I've said this before, but it bears repeating. 


David Mathog
mathog at seqvax.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech 

More information about the Bio-soft mailing list

Send comments to us at biosci-help [At] net.bio.net