🚀 go-pugleaf

> 
> Now, how can I get around this?  I want to write a one of
> the aforementioned special system processes that can write
> to the Workspace without Public Window Server being set but
> have no idea what the Workspace is looking for...
> 

I have found one way to do this.  It's not particularly elegant, but it  
works, and it allows each user to enable/disable the feature.  I mention  
using Speaker/Listener because I know it works under these circumstances,  
but Distributed Objects would probably be the best way to go.

First, write a Workspace daemon that has a known public Listener.  To do  
this, you will need the publicCheckInAs: method documented in the latest  
NeXTanswers, otherwise you cannot create a public Listener without turning  
on Public Window Server.

Workspace daemons are non NeXTSTEP programs with a .daemon extension that  
are launched by the WS at login time.  You use the LaunchPaths default to  
get this to happen.  The most elegant way is to have the daemon install  
the default the first time it is run.

Anyway, the user logs in, and the daemon is run as a user process.  Now,  
you write a command-line utility that looks for the known Listener port,  
and sends it a predetermined message (ie. displayMessage:(char *)msg.  The  
daemon pops up a panel, and the job is done.

The only problems I can think of are that (1) each user must install the  
daemon and (2) this won't display a panel on the login screen.  Still, I  
think it would be a handy way to broadcast a message to logged-on users.

Hmm. It's the last day before my XMas holiday, I'm bored, and I realize  
that my answer is a bit obscure.  I'll see if I can get this working in  
the next couple of hours and post it on an archive site.  No promises :-)

---

Gary Ritchie
gary@nshade.uah.ualberta.ca
NightShade Software