On Thu, 14 Apr 2005 19:38:26 +0200, rumours say that harold fellermann <[EMAIL PROTECTED]> might have written:
>> 1. Are you doing an single process application that produces output on >> many terminals? ie the program is kind of like a service? >gotcha. I want to write a TCP server that handles incoming requests in >threads (one thread per request using SocketServer.ThreadingTCPServer). >Now, I want the server to use curses for client-server communication >(client will be telnet). Thus, my programm runs in a single process >(although several threads) and provides several curses screens (one for >each client.) I see. At first, here is some relevant source from Modules/_cursesmodule.c : """ A number of SysV or ncurses functions don't have wrappers yet; if you need a given function, add it and send a patch. Here's a list of currently unsupported functions: addchnstr addchstr chgat color_set define_key del_curterm delscreen dupwin inchnstr inchstr innstr keyok mcprint mvaddchnstr mvaddchstr mvchgat mvcur mvinchnstr mvinchstr mvinnstr mmvwaddchnstr mvwaddchstr mvwchgat mvwgetnstr mvwinchnstr mvwinchstr mvwinnstr newterm resizeterm restartterm ripoffline scr_dump scr_init scr_restore scr_set scrl set_curterm set_term setterm tgetent tgetflag tgetnum tgetstr tgoto timeout tputs vidattr vidputs waddchnstr waddchstr wchgat wcolor_set winchnstr winchstr winnstr wmouse_trafo wscrl """ So the answer is that, no, you can't use newterm currently. But even if you did, it's not certain that you could use multiterminal ncurses in a multithreaded environment; AFAIK in ncurses you just change the "current" term and then go on with normal curses calls; is there a "current" term per thread, or is there one per process? I couldn't find an answer in the short search I did. I am afraid you will have to make it into a 3-tier arch; that is, your server has the data model and absolutely no curses knowledge, and the clients run a middle application, interfacing ncurses I/O and server protocol. -- TZOTZIOY, I speak England very best. "Be strict when sending and tolerant when receiving." (from RFC1958) I really should keep that in mind when talking with people, actually... -- http://mail.python.org/mailman/listinfo/python-list