Path: utzoo!attcan!uunet!mcvax!inria!mirsa!daniel From: daniel@mirsa.inria.fr (Daniel Dardailler) Newsgroups: comp.windows.x Subject: XSelectEvent()... Message-ID: <142@mirsa.inria.fr> Date: 15 Mar 89 16:51:01 GMT Reply-To: daniel@mirsa.inria.fr (Daniel Dardailler) Organization: Bull Research Center. Sophia Antipolis. France Lines: 37 RWS> Trying to use the X server as the RPC intermediary for things RWS> it shouldn't be involved in is a mistake, plain and simple. OK (how can I say "not OK" for such a sentence :-), now my question is: - what is right and what is wrong when using SendEvent request for X client communications ? In addition, it would be nice if RWS or someone else would apply the theory to my particular example, re-presented below. ------ In short, xtalk is a window version of the Unix talk program (with *some* additive features, like dynamic conference mode (not only 2), history-minutes management, graphics communications, answering machine functions... ) Xtalk architecture implies several xtalk processes (one by user), each creating top-level windows on ONE X Server (one window for user input/output and n-1 only for echoing other xtalkers actions). Each time an xtalk receives a keypress event on the first window, it must echo it "locally" and send a request to all other xtalk processes, saying that they must also echoing that character in their own sender's window. Reciprocally, xtalk has to wait for X events as well as for Xtalk requests... Moreover of the portability, using X ClientMessage events for Xtalk requests is a way to have only one reading-connection. The X Server are certainly more loaded (almost in number of connections) but the problem of using a select call within the Xlib really bother me. ------ Daniel Dardailler | Email : daniel@mirsa.inria.fr BULL Centre de Sophia Antipolis | Phone : (33) 93 65 77 71 2004, Route des Lucioles | Telex : 97 00 50 F 06565 Valbonne CEDEX France | Fax : (33) 93 65 77 66 |