Path: utzoo!attcan!uunet!bloom-beacon!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!psuvax1!rutgers!aramis.rutgers.edu!athos.rutgers.edu!mende From: mende@athos.rutgers.edu (Bob Mende Pie) Newsgroups: comp.windows.x Subject: Re: Looking for a program like xtalk... Message-ID: Date: 23 Sep 89 07:28:31 GMT References: <58273@aerospace.AERO.ORG> Organization: Yows `R' us Lines: 42 To: foonberg@groucho.Aero.Org In article <58273@aerospace.AERO.ORG> foonberg@groucho.Aero.Org (Alan Foonberg) writes: > ...except that one party does not have to be running X Windows. > That is, the non-X user runs an X application on the display of > the X user. It would be similar to xtalk, except that the > non-X user would see a display on his terminal similar to the > usualy talk program. > > I imagine this could be hacked up pretty quickly. If anybody > has done so, is planning on doing so, or knows where such a > program exists. could he let me know? I looked into doing this a good bit ... when you look at the whole problem, you will se that there is more problem then you would expect. Lets base the program on the standard bsd talk protocal. If you are on your xdisplay, you type xtalk user@host, a window pops up and iniatiates a talk with some other user. I did this part in a one line shellscript using xterm and a class name. Now ... say that the person that you talked is also using a xdisplay. You talked user@heckle since that is where he is logged in. But little to your knowledge, his heckle window is closed, and has been for hours. A normal talk message might go unnoticed. To complicate things, his xdisplay is jeckle. Thus talkd on heckle has to find out where user's display is, open either a talk on this display, or open a requestor box on his display. The requestor box is also simple, the hard part is finding out where his display is. Where do you get jeckle:0.0 from. The three possibilities are a) from some magic file (this is loosing for all the obvious reasons) b) from the users enviorment. Of course this means that talkd has to check to see if your logged in and then prowl through your enviorment, and hope you have a display enviorment variable set. c) get it from some other mechanism that does not yet exist. While c is the best choice, b is the most likely implementation. Tbere should be some way to identify where your xdisplay is located. If people want system services to interact with X, this will have to be standardized. /Bob... -- {...}!rutgers!mende mende@aramis.rutgers.edu mende@zodiac.bitnet