robg@mmintl.UUCP (Robert Goldman) (05/30/85)
I've heard a lot about curses, and am considering using it in a piece of UNIX software. I was wondering if any of you out there could answer the following questions: 1) Is curses supported by most or all UNIX releases? If not, which ones don't include it? 2) Are there any terminals it doesn't work well with? 3) The man entry says "SEE ALSO _Screen_Updating_and_Cursor_Movement_Optimization:_A_Library_Package_, Ken Arnold." Any suggestions about how I should get my hands on this? Please reply by mail. Thanks, Robert Goldman MultiMate Int'l. !decvax!philabs!pwa-b!mmintl!robg
dmh@dicomed.UUCP (06/10/85)
Robert The paper could be on your system. It is also in the Xenix programmer's guide to library functions (it might be verbatium or just close to). I also would like to here the results of your other questions as well as this one: I do not see any reference to keyboard input (virtual keyboard :-) parsing. I would like to write code that uses the arrow keys in the same manner as curses allows you to move the curser on the screen. Is this possible?? Thanks in advance, Dave Hollander Dicomed Corp.
zben@umd5.UUCP (06/12/85)
I posted flames on the same point. Curses does not support input translation.
Instead, there is a terminal-independant input language for each of the Unix
screen editors. While this setup may have some merit (once you learn it you
can use any available terminal) I have a Pascal screen editor that I run on
Univac 1100 and IBM 370 systems that I would like to also support Unix. This
screen editor operates by catching the keystrokes and updating an incore image
of the current screen. Thus, it MUST know what each keystroke is doing to the
screen...
The amount of brain damage out there in the terminal world is enormous. There
are dozens of cursor addressing schemes, at least three ways of doing carriage
return/line feed, and several ways of insert/delete character/line schemes.
Without knowing any better, I had coded a separate handler procedure for each
different type of terminal. Each is only one or two pages, but at this point
my terminal handlers are bigger than the rest of the editor! I would really
like to move in the direction of terminal capabilities database, but on input
there are some real sticky questions.
For example, when you are in column one, what does a left arrow do? On many
terminals it does nothing, on many more it goes to column 80 of the previous
line, on some it goes to column 80 of the SAME line. What does an up arrow
do on line one? Unix finesses all these questions by refusing to echo the
character in these situations. On mainframes without smart echo, one does not
have that handy copout. Thus, in addition to the simple question of what code
does each key generate, these little quirks must all be represented in the
database.
One additional example. On many terminals, when you do an insert-line
operation, the cursor is left wherever it was. But, on the Heathkit, the
cursor is returned to column one! If you REALLY want to see some brain-
damage, look at the insert mode on the Datamedia 2000/3000 line.
The one example I have seen this done really well on is the Series/1 front
end for IBM 370 machines. This software talks to your cheap ASCII terminal
and presents a 3270 interface to the mainframe. Basically replaces one
brain-damaged terminal with another, i.e. attributes eat a screen posn etc.
Putting in a new terminal requires building a bunch of character lookup
tables, however, and reassembling the program, so its not quite as nice as
being database-based.
--
Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPAnaiman@pegasus.UUCP (Ephrayim J. Naiman) (06/27/85)
In-Reply-To: your article <571@umd5.UUCP> <munch, munch> > I posted flames on the same point. Curses does not support input translation. > Instead, there is a terminal-independant input language for each of the Unix > screen editors. While this setup may have some merit (once you learn it you > can use any available terminal) I have a Pascal screen editor that I run on > Univac 1100 and IBM 370 systems that I would like to also support Unix. This > screen editor operates by catching the keystrokes and updating an incore image > of the current screen. Thus, it MUST know what each keystroke is doing to the > screen... I don't understand. The curses I have does getch's fine, it even interprets function keys and allows you to turn off echo so that only your application echoes what it wants to. > For example, when you are in column one, what does a left arrow do? On many > terminals it does nothing, on many more it goes to column 80 of the previous > line, on some it goes to column 80 of the SAME line. What does an up arrow > do on line one? Unix finesses all these questions by refusing to echo the > character in these situations. On mainframes without smart echo, one does not > have that handy copout. Thus, in addition to the simple question of what code > does each key generate, these little quirks must all be represented in the > database. > > One additional example. On many terminals, when you do an insert-line > operation, the cursor is left wherever it was. But, on the Heathkit, the > cursor is returned to column one! If you REALLY want to see some brain- > damage, look at the insert mode on the Datamedia 2000/3000 line. Almost all these capabilities are defined in my terminfo. If you'd like to discuss give me a call. -- ==> Ephrayim J. Naiman @ AT&T Information Systems Laboratories (201) 576-6259 Paths: [ihnp4, allegra, mtuxo, maxvax, cbosgd, lzmi, ...]!pegasus!naiman
hansen@pegasus.UUCP (Tony L. Hansen) (06/28/85)
In article <571@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >I posted flames on the same point. Curses does not support input translation. The old versions of curses that come withh 4.X BSD did not support input translations. This feature is just one of the many features that were added by Mark Horton to his version of curses when he rewrote it. It is also one of the reasons that he rewrote it. His version is now a part of System Vr2. By saying "keypad(stdscr, TRUE);", all input through stdscr is scanned for escape sequences that match those input keys specified in the terminfo entry. When one is found, an integer is returned whose value is #define'd in <curses.h>. These tokens are named such things as KEY_LEFT and KEY_HOME. Pavel Curtis' public-domain version of Mark Horton's curses also will do this translation. I have no idea how well it works. >I would really >like to move in the direction of terminal capabilities database, but on input >there are some real sticky questions. > >For example, when you are in column one, what does a left arrow do? On many >terminals it does nothing, on many more it goes to column 80 of the previous >line, on some it goes to column 80 of the SAME line. What does an up arrow >do on line one? Unix finesses all these questions by refusing to echo the >character in these situations. On mainframes without smart echo, one does not >have that handy copout. Thus, in addition to the simple question of what code >does each key generate, these little quirks must all be represented in the >database. Define the action to be what you want it to be. As long as pressing the key only causes an escape sequence to be translated, and doesn't really move the cursor locally, you have no problems. If the cursor is only local, then you have no knowledge whatsoever that the cursor got moved. If a sequence is transmitted AND the cursor is moved, then you have a bad terminal. In many cases, terminals of the last two sorts have an escape sequence that will change the action of the function keys. This sequence should be sent out upon startup. In terminfo, such a sequence would be defined by smkx=\Exxx. >One additional example. On many terminals, when you do an insert-line >operation, the cursor is left wherever it was. But, on the Heathkit, the >cursor is returned to column one! If you REALLY want to see some brain- >damage, look at the insert mode on the Datamedia 2000/3000 line. Terminfo and termcap only define insert-line/delete-line when the cursor is in column one. Mark Horton's curses will only use those capabilities when the cursor is in column one. (You get what you pay for.) Tony Hansen hansen@pegasus.ATT.UUCP
zben@umd5.UUCP (07/02/85)
In article <2403@pegasus.UUCP> hansen@pegasus.UUCP (60545451-Tony L. Hansen;LZ 3B-315;6243) writes: >In article <571@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >>I posted flames on the same point. Curses does not support input translation. > >The old versions of curses that come withh 4.X BSD did not support input >translations. > >This feature is just one of the many features that were added by Mark Horton >to his version of curses when he rewrote it. It is also one of the reasons >that he rewrote it. His version is now a part of System Vr2. > >By saying "keypad(stdscr, TRUE);", all input through stdscr is scanned for >escape sequences that match those input keys specified in the terminfo >entry. When one is found, an integer is returned whose value is #define'd in ><curses.h>. These tokens are named such things as KEY_LEFT and KEY_HOME. > >Pavel Curtis' public-domain version of Mark Horton's curses also will do >this translation. I have no idea how well it works. > This is a welcome and worthwhile extension. I looked at doing this at one time and it looked like the only gore would be back-mapping cursor addressing sequences. Was this done? It would only seem to be useful for terminals that support light pen input by sending in addressing sequences, but I have seen at least one H19 add-on that did exactly this. Not too hard because the CRT controller chip has a light pen input that is unused (grounded). >>I would really >>like to move in the direction of terminal capabilities database, but on input >>there are some real sticky questions. >> >>For example, when you are in column one, what does a left arrow do? On many >>terminals it does nothing, on many more it goes to column 80 of the previous >>line, on some it goes to column 80 of the SAME line. What does an up arrow >>do on line one? Unix finesses all these questions by refusing to echo the >>character in these situations. On mainframes without smart echo, one does not >>have that handy copout. Thus, in addition to the simple question of what code >>does each key generate, these little quirks must all be represented in the >>database. > >Define the action to be what you want it to be. As long as pressing the key >only causes an escape sequence to be translated, and doesn't really move the >cursor locally, you have no problems. If the cursor is only local, then you >have no knowledge whatsoever that the cursor got moved. If a sequence is >transmitted AND the cursor is moved, then you have a bad terminal. In many >cases, terminals of the last two sorts have an escape sequence that will >change the action of the function keys. This sequence should be sent out >upon startup. In terminfo, such a sequence would be defined by smkx=\Exxx. > You missed the quote "on mainframes without smart echoing", specifically a Univac 1100 and an IBM ~370, the input characters are just echoed back, and the terminal, of course, does what it is supposed to do. The problem is, back in the computer, deciding what that was. Unless you want to generate an error and ignore user input up to the next newline (remember we don't get control to do anything until the next newline comes in) you HAVE to know what the terminal did... >>One additional example. On many terminals, when you do an insert-line >>operation, the cursor is left wherever it was. But, on the Heathkit, the >>cursor is returned to column one! If you REALLY want to see some brain- >>damage, look at the insert mode on the Datamedia 2000/3000 line. > >Terminfo and termcap only define insert-line/delete-line when the cursor is >in column one. Mark Horton's curses will only use those capabilities when >the cursor is in column one. > Again, the user could very well hit the insert line button anywhere on the screen. The echo causes the terminal to actually do it, and you have to know what it did in order to continue. -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA
attisswd@uokvax.UUCP (01/16/86)
I was wondering if it is possible to use curses(3) on
a different tty than you are logged in on. I have change
initscr.c to do its initialization on a file descriptor
that's passed to it.
Example:
fd = open("/dev/tty10",2);
initscr(fd);
This does not work. Since initscr() uses ioctl(2) to do its
work , I don't see why this would not work (assuming all
the permissions are right).
Stephen W. Dickson
Itec Labs
Richardson, Tx
UUCP:
{ucb,decvax,decwrl,ihnp4}!sun!{,texsun!itec3}!steve
{ut-sally,rice,okstat!uokvax,convex,sohio,ctvax,smu,}!
texsun!itec3!stevejohn@comp.lancs.ac.uk (John R. Nicol) (03/19/86)
I have been experiencing nasty problems with CURSES ("who hasn't?", I hear
you say!).
The main problem is that when one CURSES process invokes another process
which also uses CURSES, strange things happen to the display (-- I think
because the first process puts the tty in a funny state). E.g. On an adm-11
terminal, tabs seem to be changed to spaces when displayed by the new process,
positions of things on the screen get screwed up; on a SUN w/s, I get reverse
video on parts of the screen etc etc.
I thought I could beat the problem by forcing any new CURSES processes to
set the tty state back to the default -- alas, this doesn't seem to work
either.....
Anyone got any useful suggestions on this CURSES problem?
many thanks in advance,
John R. Nicol
--
UUCP: ...!seismo!mcvax!ukc!dcl-cs!john| Post: University of Lancaster,
DARPA: john%lancs.comp@ucl-cs | Department of Computing,
JANET: john@uk.ac.lancs.comp | Bailrigg, Lancaster, UK.
Phone: +44 524 65201 Ext. 4146 | LA1 4YR
Project: Cosmos Distributed Operating Systems Research