[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
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
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
Main Index |
Thread Index |