ram-ashwin@YALE.ARPA.UUCP (02/25/87)
Hi Simon!
As usual you're doing a great job, and as usual your admiring users are
sending you their list of "demands"! Actually, here are some suggestions that
would be nice to have someday or at least are nice to think about:
1. MOUSE:
a. Should be definable as a function key to emit vt100 arrow key codes (as in
micro-Emacs 3.7i). It's really nice to be able to move the cursor using
the mouse when running a remote display editor through UniTerm.
2. KERMIT:
a. A little beep at the end of a transfer (as in Gem Kermit) would save us
from watching the screen like hawks.
b. Number of bytes transferred may be more useful than number of packets
transferred. Maybe both?
c. I don't know if the Kermit protocol allows you to exchange info about the
size of a file, but if it does you could count and display the estimated
time remaining for a transfer to finish. Not essential but a nice feature.
3. UNITERM itself:
a. Starting UniTerm should be automatic; the "buffer size" menu interaction
can be avoided. Maybe add this to the "help" menu and save the info in the
UNITERM.SET file? I always just hit return to select the default anyway.
b. About the "size of UniTerm" problem, here's a suggestion: Is it possible
to split the components of UniTerm over different object files that are
loaded on demand? For example, you could have one file for XModem, one
for Kermit, one for the special fonts, etc. etc. Then if the user wants
to run Kermit you can load and run that file; if he never uses Kermit (or
whatever) he doesn't even have to know it's there.
This way you can provide all the functionality of the current UniTerm
(which is *very* nice) without making the basic program too big, by
isolating the essential parts and loading the others on demand.
Whether this will work depends on the design of UniTerm. This is only
a suggestion, of course, but it seems like one way to get the best of
both worlds.
Thanx... Whether or not you implement these suggestions, we still love
your program!
-- Ashwin.
ARPA: Ram-Ashwin@yale
UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin
BITNET: Ram@yalecs
-------