tech-userlevel archive

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

Re: terminfo vs termcap



Roy Marples wrote:
Christos Zoulas wrote:
In article <775031555b2e76dc17978bcf9ab19b9f@localhost>,
Roy Marples  <roy%marples.name@localhost> wrote:
On Sat, 6 Jun 2009 13:07:27 +0200, Martin Husemann 
<martin%duskware.de@localhost>
wrote:
On Sat, Jun 06, 2009 at 04:30:40AM +0100, Roy Marples wrote:
Those are NetBSD extensions.
We can always extent terminfo functions in a similar vein.
Doesn't that kill the whole advantage of the move?
You're ignoring the other advantages of terminfo as already discussed.

But you can achieve similar functionality like so

TERMINAL *oterm = set_curterm(nterm);
// Do some foo
set_curterm(oterm);

And sprinkle pthread_mutex_lock/unlock around each curses call so that
a terminal will not use the TERMINAL entry of another accidentally? Yes,
that would work, but it is a PITA.

Are you saying that has_colors(3) can handle this in our implementation?
If so, how?

Answering my own question :)

It appears that the basic design of curses is not thread safe in regard to changing terminals, and we would be foolish to pretend that it is.

For software that need it to be, ncurses provides use_screen and use_window funtions that are passed the screen or window, a curses callback function and a data pointer. I'm not suggesting to implement that however.

Thanks

Roy


Home | Main Index | Thread Index | Old Index