[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Desiderata. [LONG, sorry]

From: Ged Haywood
Subject: Desiderata. [LONG, sorry]
Date: Sun, 13 Jan 2002 19:10:36 +0000 (GMT)

Hi all,

[Q1] Over the last six months, largely because we are outgrowing DOS'
limitations, I have ported an office application from DOS to Linux.
It does sales invoicing, stock & credit contol etc.  It's multi-user
(no really! the DOS multi-user bit is implemented by serial interrupt
handlers).  We call it the SOS - Sales Office System.  It's about 15
years old, about 100k lines of C and C++.  Under DOS it used a simple
(and also old) screen handler package called "Disp", and now it uses
ncurses, which seems to be fine.  So far I've only been using the PC
console for testing (things can get a bit out of hand in an Xterm:)
and it doesn't use (probably never will use) soft keys, menus, forms,
panels nor pads.  I just want the system to do what it's always done.

There are a few things I'd like to see in ncurses which I don't see at
the moment (if you're gonna do it you might as well do it all:).  They
will be easy enough for me to do, it would just be that much nicer if
the screen handler would do them so I don't have to get to grips with
YetAnotherPackage(TM) or start hacking around in the kernel.  I'll be
glad to help with the labour where (and if) it's appropriate.

Wish list: of course somebody out there might be able to tell me that
all this is already covered.  If so, where?

(a) Control of the shape of the cursor - yes, I know it might involve
hardware and it might not be appropriate for ncurses to do things like
that but I thought I'd canvas opinion.  Somehow or other I'll have to
do it anyway, because I have users Out There who would be upset if the
cursor were suddenly to start doing things differently.  They are all
using the i386 console.  Dumb terminal users (users of dumb terminals,
I mean:) don't need to have any fancy screen stuff.  On the PC console
I just need to make the cursor a full character block for insert mode,
a half character block for overtype mode, and occasionally maybe make
it vanish and come back again.

(b) Control of NUMLOCK and CAPSLOCK if they exist.  And SCROLLLOCK and
SHIFTLOCK too while we're about it.  I want any little lights to light
and/or extinguish; I want the terminal, console or whatever to behave
like the user will expect it to behave when those lights are variously
lit and/or extinguished; I want it all under my control so that when I
switch windows the lights (and keyboard status) can be made to follow
the WINDOW*s or not, at my option.  I will happily deal with the code
which links a WINDOW* to its keyboard state.

(c) Permission to use the ESCAPE key freely.  Hell, it's just a key,
but a very heavily loaded one and in my view it's unacceptable for a
screen handler to place restrictions on its use.  Pesky users again.
Actually I'm using it now and I'm having no problems with timeouts on
the PC console - is the restriction only for the case of keypad=TRUE?
[I didn't spot the bit in the docs which discourages use of the escape
key for a single character function until fairly late in the day, and
I was very worried that I could have wasted a lot of time until I got
it all running.  Might I suggest that this be given more prominence?]


[Q2] It seems daft to have to maintain my system using two different
screen packages so I thought about porting ncurses to DOS.  This gets
a mention in the ncurses TO-DO file but it seems like it's been just
a mention for several years now.  Has anyone picked up the gauntlet?
I'm not saying I'd have the time to do it but if any of you has any
idea how big a job it would be then I'd be pleased to hear from you.
If it would be more than a couple of weeks then I guess I'd say that
DOS probably isn't worth it at this stage of its death.  Agreed?


[Observation] Hmmm, so your hands are tied with environment variables
like LINES and COLS but isn't it a bit high-handed to use names like
TRUE, FALSE, ERR, OK, bool and WINDOW (and box!) in the header files?
If you used something like [CURS_TRUE, CURS_ERR, curs_bool, NC_WINDOW
and curs_box it would be less likely to break existing code.  I speak
after mending a *lot* of broken code...


[PS] Since joining the list I have received truckloads of SPAM through
the list server.  Is this a common experience?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]