expounded in
news:528c128e-2af7-4e56-940b-c46bd3a4f9a3@[EMAIL PROTECTED]
>> But I think
>> that curses provides so many advantages over using terminfo directly
>> (like panels for example), that I wouldn't work at the terminfo level
>> except as a last resort. Curses can simplify your work as well, and
>> yet be efficient with the traffic sent to the terminal/window. This
>> allows you to "redraw" a windowed field completely, but curses will
>> only send the parts that have changed for example.
>
> I have a reason to use terminfo instead of curses. I have also
> a screen/console driver which is based on curses (scr_cur.c).
> But years ago I found some bugs which came from the curses
> library.
Curses has come a long way since then. ;-) Ncurses ports well to posix
platforms (I tend to use ncurses on HP-UX platforms for example).
> Function keys were sometimes not recognized correctly. This
> leaded to garbage in a file edited with an editor based on
> the curses driver. The cause of the error was as follows:
> When the terminal is connected with a slow line it can happen
> that the escape sequence sended by function keys are not sended
> in one transmission. The function key recognition may get the
> escape character first. The function key recognition tries to
> take this into account be using a timeout.
Ya, this can be a problem on very slow lines, but who uses 150/300 baud
serial lines today? Besides that, it is probably a bad idea to support
terminal functions with one key-binding. If you allow a function for F3,
then bind it another way as well, using a control key or something that
can be guaranteed to be there.
Even if you insist on doing your own input, you can still use curses for
screen output. You are not locked into using their input routines. Though
I don't see any modern reason not to use them.
> I want to support the SOUND statements of GW-BASIC in the Bas7
> interpreter. For that reason I need a driver for a simple sound
> interface which comes near to the BASIC SOUND statements. I
> have some C function like:
>
> void doSound (int frequency);
>
> in my mind (frequency 0 should stop the sound).
> Since you mentioned the implementation of BDB-BASIC, various
> linux distributions and windows you have probably already a
> solution for my problem. Hos does your sound driver look like?
My sound interface consists of:
01000 PRINT CRT(BEEP)
;-)
In otherwords, the curses beep() call (which might not beep at all,
flashing instead depending upon the terminal emulation & mode).
If I was to tackle it, I'd probably look at SDL first, mainly for
portability reasons. I'm just not how mature it is yet for portability--
obviously successful games are using it:
http://www.libsdl.org/
<Excerpt>
Simple DirectMedia Layer is a cross-platform multimedia library designed
to provide low level access to audio, keyboard, mouse, joystick, 3D
hardware via OpenGL, and 2D video framebuffer. It is used by MPEG
playback software, emulators, and many popular games, including the award
winning Linux port of "Civilization: Call To Power."
SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD,
NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains
support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS,
SymbianOS, and OS/2, but these are not officially supported.
SDL is written in C, but works with C++ natively, and has bindings to
several other languages...
</Excerpt>
Good luck!
Warren.
--
Posted via a free Usenet account from http://www.teranews.com
|
