martin@mwtech.UUCP (Martin Weitzel) (12/12/89)
In order to be constructive and not to flame anybody, I think to
give some 'rules', for writing 'portable' application using curses:
1) Screen size:
Keep attention to LINES and COLS. Your program may put a lower
limit to the values and terminate with a message, that the screen
is too small. Common screen sizes are at least 24x80 today, but if
your application could run on a 20x64 screen, you give the user
some room for "decoration", esp. if the application is run in
a windowing environment.
2) Video Attributes:
Use video attributes only to *emphasize* an information, not as
the information itself. Though you may assume, todays terminals
have (at least) modes for
- blinking
- underlining
- reverse video
- half intensity
and that the modes can be selected in *any* combination without
occupying space on screen, be aware, that on certain hardware
some combinations might not work as desired.
If you absolutely need a video attribute to *show* information
(eg. higlighting a selected menu item) and that information is
*not* presentable in another way (eg. putting brackets to the left
and right), use "standout mode", because this mode can allways be
assumed to be the "best visible" video attribute on a given screen.
(For maximum portability, leave one space before and after the
part you mark in this way; then it is possible to "fool" curses
via the termcap/terminfo-entry and even have some mark on very
old hardware, with no support for video attributes.)
3) Key codes:
Newer versions of curses support "keypad()", a nice feature, which
helps to detect "multi character keys" (eg. keyboards sending
ESC-[-D for cursor right). Make use of this feature, but be aware,
that not all hardware has all the keys, definde as KEY_-tokens in
<curses.h>. For portable applications allways design an alternate
way to select a given functionality - NEVER DEPEND ON THE EXISTANCE
OF A CERTAIN KEY. (I know of applications, you can not terminate
in a controlled way, if some key is accidentially missing from
the definitions in termcap/terminfo.)
IMHO, it's save to assume that the four "ARROW"-Keys and "HOME"
are present on any todays keyboard, as well as ten F-Keys.
BTW: My personal style is, to give the user the ability to "remap"
the curses KEY_-tokens with respect to the functionality of the
application. So, anybody can setup a preferred style for using
the special keys of his/her keyboard.
Martin Weitzel
P.S.: As I'm sometimes teaching courses on curses, I'd appreciate
any additions to the above list, if accompanied by a rationale.davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (12/13/89)
In article <532@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: | Use video attributes only to *emphasize* an information, not as | the information itself. Though you may assume, todays terminals | have (at least) modes for | - blinking | - underlining | - reverse video | - half intensity You may assume such a thing, but I wouldn't use anything but standout if you want maximum portability. There are too many really dumb terminals still out there. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
scott@bbxsda.UUCP (Scott Amspoker) (12/13/89)
In article <1916@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >In article <532@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >| Use video attributes only to *emphasize* an information, not as >| the information itself. Though you may assume, todays terminals >| have (at least) modes for >| - blinking >| - underlining >| - reverse video >| - half intensity > > You may assume such a thing, but I wouldn't use anything but standout >if you want maximum portability. There are too many really dumb >terminals still out there. I believe that's what the poster was saying - that you shouldn't *depend* on the existence of such attributes but it doesn't hurt to use them if they are available. Software can take advantage of optional features and still be "portable". I agree that there are still many dumb terminals out there. I also feel that if I were developing a serious word processor it would be reasonable to exclude dumb terminals completely. Sophisticated software deserves a sophisticated environment although it's hard to know where to draw the line. When do optional features become required features? It's all market driven, of course. There is too much good software on the market to justify dumb terminals any more. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
wls@csd4.csd.uwm.edu (Bill Stapleton) (12/13/89)
In article <532@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >... some 'rules', for writing 'portable' application using curses: >3) Key codes: > IMHO, it's save to assume that the four "ARROW"-Keys and "HOME" > are present on any todays keyboard, as well as ten F-Keys. I think its best to stay away from function keys - There are only nine on this Zenith Z-49, and the first 4 have been reprogrammed to useful strings. You also have to account for key labelling - I guess I have ten F-keys, but one is labelled "HELP", not to be confused with PF1 - PF4 or F5 - F9. I used to have an old klunker at home that used ^Z in one of its arrow-key sequences, unusable with csh. In fact, if you want to be really safe, I think you're better off not assuming anything. There are still places with ancient terminals, and what with programmable keys and stuff, there's no telling what the user can actually input. I like the common practice of recognizing alternate key sequences, like arrow keys AND h-j-k-l, so people can use whatever works best. If I get a program that says type F1 to gorf, I'm stuck... -- Bill Stapleton wls@csd4.csd.uwm.edu uwmcsd4!wls
daveh@marob.masa.com (Dave Hammond) (12/13/89)
In article <532@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >2) Video Attributes: > - blinking > - underlining > - reverse video > - half intensity Don't depend on anything except reverse video ("standout") if you expect to port to most Termcap-based curses implentations (the majority of the BSD-derived world). Only Terminfo-based curses supports the additional attributes. >3) Key codes: > Newer versions of curses support "keypad()" Like video attributes, don't depend on most Termcap-based curses implementations to provide a keypad() function. Actually, I find this a bit curious since the Termcap database has always contained key pad and function key capabilities. -- Dave Hammond daveh@marob.masa.com uunet!masa.com!marob!daveh
martin@mwtech.UUCP (Martin Weitzel) (12/14/89)
In article <532@mwtech.UUCP> I gave some hints for using curses in
a portable way. Because there was some feedback since then via email,
I'd like to post this update. Thanks to all, who responded.
Before I start, one clarification: The term 'portability' is, of
course, a little weak. What portability exactly means to you, the
reader of this posting who wants to follow my hints, is your decission.
If you are working in an environment, where some of the terminals
in use are older than some of the readers of this news group, clearly
other constraints apply, as when your only concern is to port to
'PC'-type hardware of different brands.
Now, the additions mailed to me:
1) Only assume a screen size of 22x79 to be 'standard' today.
It helps curses to circumvent nasty problems on some hardware,
when the last column (esp. in the last row) must be written
to. (IMHO, you should try to put all essential information
in a 20x64 size window, but make use of the additional space
for optional information if LINES and COLS show, that the
screen is larger.)
2) Even on newer (workstation type) hardware, there are sometimes
not all the listed attributes (blink, underline, reverse, half
intensity) available. Because my first posting might not have
been quite clear in this concern, I have to repeat: You *may*
use this features, to make your application look "nicer", but
*don't* use the video attributes to output any important
information.
Eg if you want the user to select one of several menu-items by
typing <space> and <backspace>, you may mark the actually selected
item with any video attribute you like, but *additionally* mark it
in some other way, eg putting braces arround it.
If, for some reason, you don't want to do the latter, in any
case use 'standout mode', because this is the only mode allways
mapped to a clearly discernable representation on the screen.
3) I no more think it is safe to assume the availability of 10 F-Keys.
The main reason, that changed my mind, is that the F-Keys are
sometimes reprogrammable. So, let the F-Keys alone, they should
be whatever the user likes. Furthermore, there is sometimes no
distinction between the "DOWN ARROW"- and the "NEW LINE"-Key.
(Though it are two different keys, they send the *same* code on
not so few hardware.)
IMHO, the most friendly approach is to have a user specified
mapping of the *functionality* of your software to the KEY_-Tokens
of curses. In addition to the KEY_-Tokens let the user map CTRL-
Codes (0x01 .. 0x1F)(@) as well as a common prefix-code followed
by an regular key(@@) to give a work-arround for the rare case,
the poor has no special keys at all on the terminal.
(@)Some codes may be reserved for flow-control and other hardware
or system dependend functions, but most are available.
(@@)This is an 'easy to program' approach - you don't need to go and
re-invent the curses keypad()-facility, it allready exists :-)
--
<<< MW -- email: see header -- voice: 49-(0)6151-6 56 83 >>>