Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.wizards
Subject: Hints for using curses (was Re: curses - problem... NO)
Message-ID: <532@mwtech.UUCP>
Date: 12 Dec 89 10:16:50 GMT
References: <21708@adm.BRL.MIL> <8074@cs.yale.edu> <1899@crdos1.crd.ge.COM>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 54

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.