jgd@rsiatl.UUCP (John G. DeArmond) (11/20/90)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >Don't know much about Oracle, but for an interface tool Vermont Views is >real good. Good design tool (it will dump interface libraries to be read >by your run-time code, or dump C code so you can twiddle bits), Full range >of control functions from the high menu level to the low before, during >and after field functions (The point is that you have as much control as >you want to use). Connor, Not to sound belligerant but I wonder if you've used the Unix version much. At my last client, we sweated nails with it. It works BUT... The biggest problem is that it do not work through curses and instead they invented a "better idea". You are pretty much stuck with vt100/ansi terminals and the AT386 terminal as implemented in ISC Unix 2.2 does NOT work. The screen splatters enough to not be readable. Plus the screen update is not smart so you end up with really slow screens over communications lines. I gave up on trying to use VV on the console of our Compaq development system and used NCSA Telnet over ethernet which worked pretty well. I'm still looking for a high level screen interface library and editor that works through curses or at least knows how to use a standard terminfo. John -- John De Armond, WD4OQC | "Purveyors of Performance Products Rapid Deployment System, Inc. | to the Trade " (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd | "Vote early, Vote often"
chip@tct.uucp (Chip Salzenberg) (11/22/90)
[ Followups to comp.unix.sysv386 ] According to jgd@rsiatl.UUCP (John G. DeArmond): >It do not work through curses and instead they invented a "better idea". This complaint is valid. Why invent /etc/vvtermcap when /etc/termcap is 90% of what you need? Although that last 10% includes most of the neat display features, like color escape codes. >You are pretty much stuck with vt100/ansi terminals and the AT386 >terminal as implemented in ISC Unix 2.2 does NOT work. These complaints are unfounded. We use VV under SCO Unix, and I've used it under SCO Xenix, and the console is in fact the place where it works best. And if the behavior isn't right for a given terminal, just edit /etc/vvtermcap; no biggy. >Plus the screen update is not smart so you end up with really slow >screens over communications lines. Yes. I wonder about programmers who clear the screen by displaying 2000 spaces! No, I take that back -- I don't wonder about them. I worry that they might be writing nuclear power plant software next. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I've been cranky ever since my comp.unix.wizards was removed by that evil Chip Salzenberg." -- John F. Haugh II
price@chakra.unl.edu (Chad Price) (11/26/90)
In <274AD9FB.218D@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >[ Followups to comp.unix.sysv386 ] >According to jgd@rsiatl.UUCP (John G. DeArmond): >>It do not work through curses and instead they invented a "better idea". >This complaint is valid. Why invent /etc/vvtermcap when /etc/termcap >is 90% of what you need? Although that last 10% includes most of the >neat display features, like color escape codes. >>You are pretty much stuck with vt100/ansi terminals and the AT386 >>terminal as implemented in ISC Unix 2.2 does NOT work. >These complaints are unfounded. We use VV under SCO Unix, and I've >used it under SCO Xenix, and the console is in fact the place where it >works best. And if the behavior isn't right for a given terminal, >just edit /etc/vvtermcap; no biggy. We use VV on an AT&T 386 running Sys V, 3.2 and display to both the console (in color, but with limitations - one of us has altered their shrouded source in order to allow more color combinations to work), and to AT&T 605 terminals (monochrome.) We are working on vvtermcaps for AT&T 320 graphics terminals (slowly - not a top priority). While creation of yet another termcap is a nusance (!!), since the regular termcap does not support many of the nicer features, it seems the only reasonable option. I'd be interested in hearing from others using VV to learn from their findings about VV bugs and VV shortcuts, etc. Chad price@fergvax.unl.edu
jgd@rsiatl.UUCP (John G. DeArmond) (11/26/90)
>>You are pretty much stuck with vt100/ansi terminals and the AT386 >>terminal as implemented in ISC Unix 2.2 does NOT work. >These complaints are unfounded. We use VV under SCO Unix, and I've >used it under SCO Xenix, and the console is in fact the place where it >works best. Interesting concept. Stating that my complaining about a problem with the configuration that I use is unfounded and then citing another environment entirely to support the claim. I should be so bold! I will restate again. The AT386 terminal as implemented in ISC Unix 2.2 (key on ISC) installed on a Compaq DeskPro 33 with the internal Compaq VGA does NOT work. >And if the behavior isn't right for a given terminal, just edit >/etc/vvtermcap; no biggy. Depends on what one views as prudent use of one's time and in this case, the client's money. If you consider it acceptable for a commercial package of a quite substantial price to require hacking before use, and f you consider it proper to bill your client for said hacking, then it is no big deal. Otherwise it IS a big deal considering that ISC unix already comes with a terminfo database that works just fine. John -- John De Armond, WD4OQC | "Purveyors of Performance Products Rapid Deployment System, Inc. | to the Trade " (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd | "Vote early, Vote often"
woods@eci386.uucp (Greg A. Woods) (11/29/90)
In article <price.659585351@chakra> price@chakra.unl.edu (Chad Price) writes: > In <274AD9FB.218D@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > >>It do not work through curses and instead they invented a "better idea". > > >This complaint is valid. Why invent /etc/vvtermcap when /etc/termcap > >is 90% of what you need? Although that last 10% includes most of the > >neat display features, like color escape codes. >[....] > >works best. And if the behavior isn't right for a given terminal, > >just edit /etc/vvtermcap; no biggy. >[....] > While creation of yet another termcap is a nusance (!!), since the regular > termcap does not support many of the nicer features, it seems the only > reasonable option. Nope. In fact, maintaining several different types of "termcap" databases is the worst possible nightmare for an administrator. I know, since I've done it (for curses, Word Era, Word Perfect, and Business Basic; and there were only three different types of terminals!). NEVER AGAIN! Uniplex almost got it right, though their system is a wee bit too "dumb" to work well. They attempt to automatically intuit what can be gathered from either terminfo or termcap, and convert to their own "database". However, their system is extremely complex to maintain, especially for site which has to maintain curses databases for other applications. In addition, Uniplex fails in tasks where curses shines (e.g. with the LINES/COLUMNS variables). Neither do they utilize all of the possible info in a termcap or terminfo entry (eg. acsc). Now, as for VV, I have no first-hand opinions. I refuse to use a package that does not use the existing facilities of UNIX properly. Curses (and termcap or terminfo) have done a wonderful job for many applications, and there is absolutely no need to re-invent them. I have used two packages which I would recommend to anyone needing a layer of functionality between curses and their application. The most complex and complete package is C-Scape from The Oakland Group. The least complex is a shareware package called fast from Apsen Scientific. Neither of these packages use anything more than bare curses (although fast will work with Aspen's enhanced curses). Both provide much of the advanced functionality for a character interface some people want. One other third-hand opinion I've heard about VV is it is difficult to use, and seems to require very convoluted and complex code. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA