home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / next / programm / 7884 < prev    next >
Encoding:
Text File  |  1992-12-22  |  2.4 KB  |  53 lines
  1. Newsgroups: comp.sys.next.programmer
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!news
  3. From: gary@nshade.uah.ualberta.ca (Gary Ritchie)
  4. Subject: Re: How to open a connection without PublicWindowServer set?
  5. Message-ID: <1992Dec22.220807.5205@kakwa.ucs.ualberta.ca>
  6. Sender: news@kakwa.ucs.ualberta.ca
  7. Nntp-Posting-Host: nshade.uah.ualberta.ca
  8. Organization: University Of Alberta, Edmonton Canada
  9. References: <1992Dec22.011725.10555@almserv.uucp>
  10. Date: Tue, 22 Dec 1992 22:08:07 GMT
  11. Lines: 40
  12.  
  13. > 
  14. > Now, how can I get around this?  I want to write a one of
  15. > the aforementioned special system processes that can write
  16. > to the Workspace without Public Window Server being set but
  17. > have no idea what the Workspace is looking for...
  18. > 
  19.  
  20. I have found one way to do this.  It's not particularly elegant, but it  
  21. works, and it allows each user to enable/disable the feature.  I mention  
  22. using Speaker/Listener because I know it works under these circumstances,  
  23. but Distributed Objects would probably be the best way to go.
  24.  
  25. First, write a Workspace daemon that has a known public Listener.  To do  
  26. this, you will need the publicCheckInAs: method documented in the latest  
  27. NeXTanswers, otherwise you cannot create a public Listener without turning  
  28. on Public Window Server.
  29.  
  30. Workspace daemons are non NeXTSTEP programs with a .daemon extension that  
  31. are launched by the WS at login time.  You use the LaunchPaths default to  
  32. get this to happen.  The most elegant way is to have the daemon install  
  33. the default the first time it is run.
  34.  
  35. Anyway, the user logs in, and the daemon is run as a user process.  Now,  
  36. you write a command-line utility that looks for the known Listener port,  
  37. and sends it a predetermined message (ie. displayMessage:(char *)msg.  The  
  38. daemon pops up a panel, and the job is done.
  39.  
  40. The only problems I can think of are that (1) each user must install the  
  41. daemon and (2) this won't display a panel on the login screen.  Still, I  
  42. think it would be a handy way to broadcast a message to logged-on users.
  43.  
  44. Hmm. It's the last day before my XMas holiday, I'm bored, and I realize  
  45. that my answer is a bit obscure.  I'll see if I can get this working in  
  46. the next couple of hours and post it on an archive site.  No promises :-)
  47.  
  48. ---
  49.  
  50. Gary Ritchie
  51. gary@nshade.uah.ualberta.ca
  52. NightShade Software
  53.