Abusing `curses' WINDOW structure
Brian Yost
of the curses library.
I'm writing a program which uses the curses library, and need to
include a "print screen" type of utility. Rather than reproducing
my display logic in order to print a text file image, I was thinking
of simply copying the screen from stdscr->_y directly into my textfile
(adding newlines where appropriate). Something along these lines:
PrintScr(f, win)
FILE *f;
WINDOW *win;
{
register short i, j;
for (i = 0; i < win->_begy; i++)
fputc('\n', f);
for (i = 0; i < win->_maxy; i++) {
for (j = 0; j < win->_begx; j++)
fputc(' ', f);
for (j = 0; j < win->_maxx; j++)
fputc(win->_y[i][j], f);
fputc('\n', f);
}
fflush(f);
}
Now, my machine uses termcap, and this seems to work OK. The question
is, is the WINDOW structure different in the terminfo implementation?
And if so, can the routine above be rewritten and made to work?
Please reply by mail, and thanks.
Brian Yost {clyde,topaz}!infopro!bty!yost
``This is a sic (sic) joke.''
Guy Harris
> include a "print screen" type of utility. Rather than reproducing
> my display logic in order to print a text file image, I was thinking
> of simply copying the screen from stdscr->_y directly into my textfile
> Now, my machine uses termcap, and this seems to work OK. The question
> is, is the WINDOW structure different in the terminfo implementation?
> And if so, can the routine above be rewritten and made to work?
"Abusing" is right! Assuming you "know" what an unadvertised data structure
of a package looks like is a great way to get into trouble.
Yes, the window structure is different, although that sort of thing will
sort of work. Don't do it, though. There is a macro "winch" that returns
the "character" at the current position on the screen. Use that instead.
"character" is in quotes, because it masks out the character attributes in
the 4BSD "curses" but not the S5 "curses". You should mask the result of
that operation with 0177 if you just want the character. (Note that your
sample code would not work properly for characters in standout mode; the raw
data in the screen buffer has high bits set if the character has an
attribute turned on.)
This stuff is documented both in the 4.2BSD and the S5 "curses"
documentation. Please, people, before you decide you have no choice but to
sneak around the back door of a facility, check out the documentation - in
painful detail, if need be - first!
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com (or g...@sun.arpa)
Brett Galloway
>> I'm writing a program which uses the curses library, and need to
>> include a "print screen" type of utility. Rather than reproducing
>> my display logic in order to print a text file image, I was thinking
>> of simply copying the screen from stdscr->_y directly into my textfile
>> (adding newlines where appropriate). ...
>> Now, my machine uses termcap, and this seems to work OK. The question
>> is, is the WINDOW structure different in the terminfo implementation?
>> And if so, can the routine above be rewritten and made to work?
>
>"Abusing" is right! Assuming you "know" what an unadvertised data structure
>of a package looks like is a great way to get into trouble.
One nit is that at least in 4.2 BSD the WINDOW structure IS advertised --
in appendix B of the document, Screen Updating and Cursor Movement
Optimization: A Library Package, by Kenneth Arnold.
Nonetheless, I do agree that use of the internals of WINDOW is
dangerous. However, there are cases where such use is unavoidable.
I have a program in which a WINDOW is passed as an argument to a function
which needs to know the bounds of the window. At least in 4.2BSD, I know
of no portable way to deduce that from the WINDOW structure, although the
fields are apparent enough. Therefore, I used the _maxx and _maxy fields.
Further, the only portable way I know to get the current coordinates in a
window is to use getyx(win,y,x); but frequently one only wants one of the
coordinates and not both. Getyx() forces the user to provide variables for
both coordinates, and then lint barks about a variable set but not used.
In short, curses (at least 4.2BSD) doesn't provide enough functionality
through macros to avoid nonportable uses.
More generally, I find curses well-named. Even excluding the many bugs
that exist in the 4.2 BSD implementation, it does not provide sufficient
functionality, and it is virtually possible to extend its
functionality in a portable manner. What I would like to see is someone
define and implement a new package similar to curses but more powerful.
This package should have a well-defined interface to the
underlying terminal driver library, allowing termcap and terminfo drivers
to be written for it, and even drivers for certain pc's. It should also
have separate drivers for controlling system-dependent information, such
as the BSD job-control-dependent stuff in 4.2 BSD curses. It
should provide a more coherent and general mechanism for performing
input through windows. Finally, it should provide a rational method to
treat dynamic window resizing, which I understand occurs on at least one
system, SUN, and which can be expected to appear on others.
I don't understand why it would not be possible to take the display end of
one of the powerful, portable editors and turn it into a display package of
this sort. If done right, the core of the package could be completely
portable across systems both unix and non-unix. As such, the package could
become a de facto standard for video character display handling for the C
language. Far too often people keep re-inventing this package for different
editors, even under unix systems (because curses isn't powerful or general
enough).
--
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett
Guido van Rossum
In article <7...@wjvax.wjvax.UUCP> br...@wjvax.UUCP (Brett Galloway) writes:
>... What I would like to see is someone
>define and implement a new package similar to curses but more powerful.
>This package should have a well-defined interface to the
>underlying terminal driver library, allowing termcap and terminfo drivers
>to be written for it, and even drivers for certain pc's. It should also
>have separate drivers for controlling system-dependent information, such
>as the BSD job-control-dependent stuff in 4.2 BSD curses. It
>should provide a more coherent and general mechanism for performing
>input through windows. Finally, it should provide a rational method to
>treat dynamic window resizing, which I understand occurs on at least one
>system, SUN, and which can be expected to appear on others.
>
>I don't understand why it would not be possible to take the display end of
>one of the powerful, portable editors and turn it into a display package of
>this sort. If done right, the core of the package could be completely
>portable across systems both unix and non-unix. As such, the package could
>become a de facto standard for video character display handling for the C
>language. Far too often people keep re-inventing this package for different
>editors, even under unix systems (because curses isn't powerful or general
>enough).
Well spoken. Our group has designed and written a package which looks
like it would be a good start. I am posting its specification here to
evoke reactions. Implementations are available for Unix (termcap only,
runs under 4.{1,2,3} BSD, v7 and System 5) and MS-DOS (Monochrome or
Color (CGA, not EGA) monitor). It wouldn't be hard to write a version
for the Macintosh, Amiga or Atari ST; in fact I once hacked together a
Mac version but it isn't in distributable form.
Some things it doesn't do for now: low-level character-I/O, comparable
to curses' move and addch; multiple overlapping windows (though
Emacs-style windows are trivial to implement on top of it).
What it does do, although it doesn't show from the specs, is extensive
optimization of redudant operations within a screen line (using
insert/delete character if available and useful, for instance).
Like Brett suggests, this package was designed as the display part of a
powerful, portable editor. It has served in at least three different
editors I have written, one of which I am using right now to type this
message.
If you want the code, write to me and I can mail it to you; it'll be
free but copyrighted and available for non-commercial use only.
However, the kind of reactions I would like to see most are those
proposing a kind of cooperation on the further development of this
package to fill the need of a larger group of users, and make it a
de-facto standard for portable screen/window manipulation. Discussion
in this group seems also fine.
Guido van Rossum, CWI, Amsterdam <gu...@mcvax.uucp>
----------------------------------------------------------------------
Note: these specs are public domain!
/*
* The VTRM package (Virtual TeRMinal).
*
* This package uses termcap to determine the terminal capabilities.
*
* The lines and columns of our virtual terminal are numbered
* y = {0...lines-1} from top to bottom, and
* x = {0...cols-1} from left to right,
* respectively.
*
* The Visible Procedures in this package are:
*
* trmstart(&lines, &cols, &flags)
* Obligatory initialization call (sets tty modes etc.),
* Returns the height and width of the screen to the integers
* whose addresses are passed as parameters, and a word of flag
* bits that describe some capabilities (specs available on request).
* Function return value: 0 if all went well, an error code if there
* is any trouble. No messages are printed for errors.
*
* trmundefined()
* Sets internal representation of screen and attributes to undefined.
* This is necessary before a hard redraw, which would get optimized to
* oblivion.
*
* trmsense(&y, &x)
* Performs a 'cursor sense' if available on the hardware.
* Returns the cursor position through its parameters
* after a possible manual change by the user; these are set
* to -1, -1 if no sense is possible (this may be a temporary
* or permanent condition).
*
* trmputdata(yfirst, ylast, indent, data)
* Fill lines {yfirst..ylast} with data, after skipping the initial
* 'indent' positions. It is assumed that these positions do not contain
* anything dangerous (like standout cookies or null characters).
*
* trmscrollup(yfirst, ylast, by)
* Shift lines {yfirst..ylast} up by lines (down |by| if by < 0).
*
* trmsync(y, x)
* Call to output data to the terminal and set cursor position.
*
* trmbell()
* Send a (possibly visible) bell, immediately (flushing stdout).
*
* trmend()
* Obligatory termination call (resets tty modes etc.).
*
* You may call these as one or more cycles of:
* + trmstart
* + zero or more times any of the other routines
* + trmend
* Trmend may be called even in the middle of trmstart; this makes it
* possible to write an interrupt handler that resets the tty state
* before exiting the program by simply calling trmend.
*
* trminput()
* Return the next input character (with its parity bit cleared
* if any). This value is a nonnegative int. Returns -1 if the
* input can't be read any more. Input is not echoed.
*
* trmavail()
* Return 1 if there is an input character immediately available,
* 0 if not. Return -1 if unknown.
*
* THE FOLLOWING SPECS ARE TENTATIVE ADDITIONS:
*
* trminterrupt()
* Return 1 if an interrupt has occurred since the last call to
* trminput or trmavail, 0 else. [Currently not implemented.]
*
* trmsuspend()
* When called in the proper environment (4BSD with job control
* enabled), suspends the editor, temporarily popping back to
* the calling shell. The caller should have called trmend()
* first, and must call trmstart again afterwards.
* BUG: there is a timing window where keyboard-generated
* signals (such as interrupt) can reach the program.
*/
Tony L. Hansen
< >define and implement a new package similar to curses but more powerful.
< >I don't understand why it would not be possible to take the display end of
< >one of the powerful, portable editors and turn it into a display package of
< >this sort.
< > As such, the package could
< >become a de facto standard for video character display handling for the
< >C language. Far too often people keep re-inventing this package for
< >different editors, even under unix systems (because curses isn't
< >powerful or general enough).
It was precisely because of the problems with the BSD version of curses
which caused the System V version of curses to be created. The original
version of System V curses was indeed based on the display end of one of the
newer "powerful, portable editors" (Gosling's Emacs). All of that code was
subsequently rewritten to make it even more powerful and faster. (For that
matter, the BSD curses display code was taken from Vi.)
The Vr3 curses was made much faster, and you should see how slick (fast and
small!) the Vr3.1 version of curses is. When this version of curses becomes
available, I can see no reason for wanting to write one's editor on top of
anything else.
Tony Hansen
ihnp4!pegasus!hansen
Doug Gwyn
>The Vr3 curses was made much faster, and you should see how slick (fast and
>small!) the Vr3.1 version of curses is. When this version of curses becomes
>available, I can see no reason for wanting to write one's editor on top of
>anything else.
It sounds nice, but I'm afraid that it will see relatively little use
until and unless SVR3.1 has a more sensible licensing policy. Many
vendors decided not to license SVR3.0 due to the silly SVID clause.
Perhaps you're in a position to recommend a change in this?
Guido van Rossum
>For that matter, the BSD curses display code was taken from Vi.
The BSD curses code cannot have been taken from VI because VI does not
contain something like curses. BSD termcap code was taken from VI, but
this is only a set of four or five routines.
>The Vr3 curses was made much faster, and you should see how slick (fast and
>small!) the Vr3.1 version of curses is. When this version of curses becomes
>available, I can see no reason for wanting to write one's editor on top of
>anything else.
Availability. Basing software on AT&T curses limits the distribution
range quite seriously (especially in the academic world, I suspect).
If you have to fall back on BSD curses where AT&T curses is not
available, it may be better to write something yourself on top of
termcap.
--
Guido van Rossum, CWI, Amsterdam <gu...@mcvax.uucp>
(PS: I've sent my code to Rich Salz. He said it will take a few weeks
before it goes out...)
Jeff Lee
>>small!) the Vr3.1 version of curses is. When this version of curses becomes
>>available, I can see no reason for wanting to write one's editor on top of
>>anything else.
>Availability. Basing software on AT&T curses limits the distribution
>range quite seriously (especially in the academic world, I suspect).
Not to mention the stupid licensing that ATT is attempting with the Vr3
releases that should further limit the distribution of the Vr3.1 release
of curses. The licensing reads something like if you include ANY part of
Vr3 then your product has to conform to the entire SVID release 3.
Am I mistaken or do they keep trying something like this? There were initially
stupid pricing policies for Honey DanBer and no educational discounts for
the DMD software (it still cost us $1000 educational for DMD). Unix is liked
by a lot of people but ATT is a long way from being IBM. If I am wrong I am
sure that SOMEONE will correct me.
Enjoy,
--
Jeff Lee
CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff