Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin From: martin@mwtech.UUCP (Martin Weitzel) Newsgroups: comp.unix.wizards Subject: Hints for using curses (updated) Message-ID: <544@mwtech.UUCP> Date: 14 Dec 89 14:14:56 GMT References: <21708@adm.BRL.MIL> <8074@cs.yale.edu> <1899@crdos1.crd.ge.COM> <532@mwtech.UUCP> <1916@crdos1.crd.ge.COM> <444@bbxsda.UUCP> Reply-To: martin@mwtech.UUCP (Martin Weitzel) Organization: MIKROS Systemware, Darmstadt/W-Germany Lines: 55 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 and , 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 >>>