klaus@relay.eu.net (klaus u schallhorn) (11/21/90)
About a year ago I was confronted with a sun [sunview] for the very first
time. After studying a ton of documentation I ported a similar ton of
applications from an old System III box to SunView. Now that some of the
applications are due for some maintenance, I want to improve on what i
kludged together.
Problem:
========
Most of my applications have to do with data entry, providing masks on the
screen. Because of some stringend verification requirements during data
entry over the years I built a small library of [screen/kb] i/o functions
that allowed very fast entering while still checking for every possible
error.
My library at the same time takes care of the handling of 8-bit character
sets, translating the host charset to whatever is used to log into the
system. Keystrokes are translated from the login terminal type charset to
the host charset [they are different, believe you me].
Since I'm using this library in virtually everything that has to do with
screen i/o, I have [only] one set of programs that runs under sunview as
well as on any terminal. If run on the console, my library actually forks
and opens a window, so that my original 2 shelltools [plus console] on the
screen are never "used up". I can move any application wherever on screen
without the need to ^Z out of a program to gain access to a shell. Handy,
except:
All my programs "suffer" from a conventional top down approach, doing
the familiar [simplyfied]:
get_something(itembuf)
char *itembuf;
{
while ((i = getkey()) != whatever_stops_this_loop)
;
}
Getkey of course is a simple read or getchar or whathaveyou if run from a
terminal. Under sunview, however, it's a loop that calls Mr Notifier and
returns in case of kb entry, or usleep()s for a while.
Although this works, you can notice the effect of calling the notifier
about 10 or 15 times a second, if you happen to have several programs
active on screen, mousing between them.
There are several reasons why I have not used "proper" sunview programming
using event notification.
A) As far as I can tell my library would be obsoleted by such an approach.
Even after brooding over this in all kinds of positions, locations and
[private], I couldn't come up with a way of constructing a similarly
general purpose library.
B) I don't believe, that having to move the mouse from field to field
instead of simply pressing return aids productivity.
C) Same reason applies to press-this-n-that when done. I use function keys
to achieve the same thing, very likely much faster.
D) I DO want to use my library, because writing new applications with this
is very fast [you just define a few structures, fill them with some
constants/data, and away you go. Sample programs including data entry,
verification, menues, windows, charset and keyboard translation between
different hardware sets are in fact no larger than plain simple curses
demo programs].
E) I don't like the idea of having separate binaries for sv & terminals.
F) I DO, however, like the approach taken when running on the console
[that is to open a separate window that can be moved, closed, stashed away
and whatever].
G) Sun now touts NeWS until somebody else dreams up an even bigger
performance hog. I certainly don't want to redo all my applications when
one day the next upgrade comes without sunview.
H) I want my programs to be faster than pretty.
The nearest thing I found [in the sunview docs] to what I really want is a
sample that opens a window on screen and then forks a shell to vi,
probably using a tty window [I saw this in the 4.0.3 manuals, I haven't
looked into the 4.1 sunview manuals yet].
Looking through the various sunview demos [sources], I couldn't find
anything the remotely resembles what I want.
Question: How have you solved similar problems? Am I to thick to build a
proper library using sunview? Where in TFM is such an approach explained?
Is the conventional top down approach really a "bad" thing now?
Operation shield: I'm not in principle against sunview or similar
techiques, I object to their [apparant] inability to do things "the old
way", and I'm certainly pleased with the kit in use [ss1]. Help, however,
is desparately needed.
Please mail, I'll summarize, if requested.