Hints for using curses (updated)

[Martin Weitzel]

In article <532 at 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 >>>