X window interface (long)

David Mathog mathog at seqvax.caltech.edu
Wed Apr 15 17:37:00 EST 1992

X windows seems to be replacing VT100/Tektronix as the new de facto 
"standard" environment for molecular biology (and other) programs.  I
don't want to discuss the technical merits of this trend, but I think
that a little thought should be given to the cost, both for
hardware/software and for effort integrating these applications.  I'll tilt
this discussion towards X window programmers and system managers (ie, those
of us who have to make software accessible to a group of users.) 

Background.  This is how things are here: we've got around 100 Macs
and PC's, one (B&W) VaxStation console, and one (B&W) SPARCstation
console. One or two of the labs have their own Unix boxes.  So,if any
significant number of these users are to have access to this new
generation of X based software using existing hardware, they are going
to need Mac and PC X window servers. At the moment, these users
utilize VT100/Tektronix mode emulation for 99% of the software that
runs on the Vax, but we've got a couple of people running MacX to use
ACEDB on the SPARC. 

And now a few questions:

1. Can your existing Unix and VMS machines support as many
   simultaneous X client applications as needed to keep the users

[Here, no way. We've only got a Sparc 1 and a VAXstation 3100m38,
that's plenty for VT100/Tek, but not nearly enough horsepower for lots
of simultaneous X sessions.] 

2. How many of your users' existing Macs and PCs could run X servers? 

[Here, about a third.  A lot of the existing systems either are too
underpowered (Mac Plus, Original PC's) or don't have enough disk or
memory.  They can pretty much all run VT100 emulators and around 90%
can also do Tektronix emulation.] 

3. How are you going to put X servers on all of those Macs and PCs? 

[Putting _legal_ copies of commercial X server packages on all of our
PCs and Macs is going to cost serious money. To give you a clue on the
environment, a lot of ours are running NCSA Telnet, MacIP, or Kermit,
ie, their owners either were not willing or not able to pay for
commercial terminal emulators.] 

4. Do any of your users dial in to use your systems? 

[Here, fewer and fewer since we've finally got the ethernet into all
of the labs.  However, quite a few people work on papers and such at
home.  Things are already pretty slow for them at 2400 baud in
character mode.  Maybe they could run X windows over SLIP, but I bet
that they wouldn't like it.] 

5. Have you ever seen public domain X window servers for PC's running
   DOS and Windows, and Mac's running System 6 or 7? 

[I've not encountered these programs, but I'd love to have them if
they already exist.] 

Now that I've grumped about the cost of the interface, here are my
suggestions to X window program developers to help us minimize these

1.  ALWAYS put in a character mode interface.  This should be in two
versions, instead of, and in addition to, the X interface. Your
program will run on practically anything and TO practically anything. 
It will also be possible to access it via scripts.  We can migrate to
its X window capabilites as our budget permits.  Yeah, I know, low
tech, stone age, etc., but guess what, a lot of us still have to work
at this level. 

2.  When you add graphics, have some way for the character mode to
send graphics to a file and to the screen.  It doesn't matter so much
if it is Tektronix, GKS, or whatever.  If we can get our hands on it,
then we can reformat it enough to look at it.  Obviously, this isn't
for interactive graphics applications.  But then, how much interactive
graphics does one _really_ need in a database? 

3   Have mercy on those users who have B&W or 4 bit grey scale
screens.  Ditto for those without 1000 x 1000 screens. 

4   Mice come with 3/2/1 buttons.  Using option up-arrow mouse-button
is a miserable way to access a program option.  Set it up so that your
program works reasonably with the number of physical buttons on the
user's mouse.  Also, stay away from weird control key mouse button
combinations - they are user hostile. 

5   How about next time you get an urge to write a graphical DNA
editor, write a public domain X server for either the PC or the Mac
instead?  Yeah, it's not a trivial undertaking (I know that I couldn't
do it), but it would be really nice to have this software around. Just
think, if you write this then you will have increased the "market" for
your other X window software by about 10x !

That's enough gasoline on the fire for one day.

David Mathog
mathog at seqvax.caltech.edu
manager, sequence analaysis facility, biology division, Caltech

More information about the Bio-soft mailing list