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
lines).
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.
Regards,
David Mathog
mathog at seqvax.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
