VNC Server

[Casey]

At last count we had six different VNC clinets that run in OS X. Has anyone heard of efforts to develop a VNC server for OS X?

I'm hoping Apple will implment remote connections to Aqua... or maybe some kind of X11 bridge... but what are the odds.

[VGZ]

I know there is at least one vnc server that works under OS X. I don't remeber the url but I think you can find it if you search the forums.

Hope this helps ,

[The DJ]

Originally posted by VGZ
I know there is at least one vnc server that works under OS X.

That was a port of the XWindow version of VNC server if i am correct.
It will only show XFree86 apps running.
What Casey probably means is a version that can serve Quartz. That is all applications, including the desktop and Mail.app that most people use in OSX.

DJ

[strobe]

Not going to happen.

VNC isn't designed for what's termed '3rd generation display servers'. In X11 or Win32 each pixel is drawn by one process directly to screen. Quartz doesn't work that way. Try dragging a semi-transparent object in Win32 over VNC and watch it slow to a crawl.

A more practical solution would be a PDF equivalent of xhost.

[zpincus]

While a PDF version of X windows forwarding would be nice, it still leaves a few gaps.
1) ssh won't be likely to be able to natively forward the PDF commands in an encrypted state. Apple will need to design a new tool for this.
2) it won't work cross-platform like VNC does.

Number 2 is why VNC is so huge for me and a lot of people I go to school with. PDF forwarding won't let me use my OS X box from, say, a windows machine, unless someone writes an XTools or eXceed type solution that is likely to be slow in coming and very expensive. (And at least Xtools only happened b/c Xfree86 is opensource -- can you imagine trying to replicate Quartz on x86 with no code to go from?)

I agree with Strobe that a VNC that deals with Quartz isn't going to be an easy port. But I don't think it will be impossible.
At some point, Quartz spits out the final, rendered screen, pixel by pixel, and sends it to the monitor. I don't see why it would be impossible for VNC to intercept this and send it on a network. Just treat Quartz as the only process that draws pixels, and ignore the other processes that interact with Quartz on earlier levels. This would also solve the transparency problem, because then I'd imagine the VNC server wouldn't bog down on transparent dragging any more than Quartz does -- because it is still Quartz's responsibility to render transparency, and not VNCServer's.

Now, this notion is a little strange to those familiar with *NIX VNCServers, where the VNCServer can actually substitute for the window server (ie: you don't need to be actively running X for VNC to work.)
But even in OS 9, VNCServer sits on top of Apple's "windows server." It can't generate an independant display on its own, and instead the VNC server mediates communication with the OS 9 display over the network. (So if you are VNCing into an OS 9 box, your mouse movements on the "VNC side" makes the cursor actually move on the screen.)
So there's a precdent for VNC servers sitting on top of and not replacing a window server... can this be extended to OS X/Quartz? I have no idea.

It might take Apple's cooperation, though, and perhaps a lot of it. And of course, my thinking on this may be totally wrong. Does anyone who has done VNC work before know if this is a totally faulty idea?

Anyway, I'm going right now to nag Apple and tell them to make it easy to do a VNC Server for Quartz, just on the off chance that it is possible.

Zach

[strobe]

Originally posted by zpincus
While a PDF version of X windows forwarding would be nice, it still leaves a few gaps.
1) ssh won\'t be likely to be able to natively forward the PDF commands in an encrypted state. Apple will need to design a new tool for this.
2) it won\'t work cross-platform like VNC does.

1) Incorrect. You can always encrypt any tcp stream. Apple will NOT have to design a new tool |-p

2) There are a few 3rd party PDF viewers. One could be converted into a remote PDF viewer. We already have display ghostscript for postscript, why not for PDF as well? (ghostscript can render PDF documents)

Number 2 is why VNC is so huge for me and a lot of people I go to school with. PDF forwarding won\'t let me use my OS X box from, say, a windows machine, unless someone writes an XTools or eXceed type solution that is likely to be slow in coming and very expensive. (And at least Xtools only happened b/c Xfree86 is opensource -- can you imagine trying to replicate Quartz on x86 with no code to go from?)

What makes you think a VNC-like solution would be faster than a PDF one?! The changes the Quartz output goes through are just as complex.

I agree with Strobe that a VNC that deals with Quartz isn\'t going to be an easy port. But I don\'t think it will be impossible.
At some point, Quartz spits out the final, rendered screen, pixel by pixel, and sends it to the monitor. I don\'t see why it would be impossible for VNC to intercept this and send it on a network. Just treat Quartz as the only process that draws pixels, and ignore the other processes that interact with Quartz on earlier levels. This would also solve the transparency problem, because then I\'d imagine the VNC server wouldn\'t bog down on transparent dragging any more than Quartz does -- because it is still Quartz\'s responsibility to render transparency, and not VNCServer\'s.

You can test your theory using Win32. It\'s not practical. You would be far better off converting ghostscript into a remote PDF viewer.

Now, this notion is a little strange to those familiar with *NIX VNCServers, where the VNCServer can actually substitute for the window server (ie: you don\'t need to be actively running X for VNC to work.)
But even in OS 9, VNCServer sits on top of Apple\'s \"windows server.\" It can\'t generate an independant display on its own, and instead the VNC server mediates communication with the OS 9 display over the network. (So if you are VNCing into an OS 9 box, your mouse movements on the \"VNC side\" makes the cursor actually move on the screen.)
So there\'s a precdent for VNC servers sitting on top of and not replacing a window server... can this be extended to OS X/Quartz? I have no idea.

It might take Apple\'s cooperation, though, and perhaps a lot of it. And of course, my thinking on this may be totally wrong. Does anyone who has done VNC work before know if this is a totally faulty idea?

Anyway, I\'m going right now to nag Apple and tell them to make it easy to do a VNC Server for Quartz, just on the off chance that it is possible.

Zach

It isn\'t, and you can confirm it yourself. Please don\'t waste your time (and possibly Apple\'s)

[scruffy]

I have read, can\'t remember where now, that Quartz has remote display capabilities buit in. Not that they\'re available right now, as of PB, and perhaps won\'t be as of 1.0, but that somewhere in the future, they could be.

Given that there is a reasonable separation between the apps and the window server/manager in OS X (unlike OS 6-9 ? ), it shouldn\'t be too difficult. VNC is horrid slow, as you all know, since it can\'t just send window events, but has to send all the pixel changes whenever you click a button, or whatever. Seems to me that since Apple have taken care to design everything with a good modular approach, remote execution might not be too difficult.

I have access to only one OS X box, but has anyone tried to ssh/telnet into one OS X box from another, and then open -a some program on the remote machine? I don\'t expect it would work, but the error messages, etc. might offer some insight into whether the architecture is there.

Also, anyone know whether there was some sort of similar ability with NeXT? Remote display on DPS should be at least a bit like remote display on DPDF, you\'d think.

[strobe]

Rumor has it DP3 supported remote display but I would have to re-install it to check.

NeXT had nxhost which follows the same concept as xhost except it piped postscript commands. The same could be done with PDF data.

It would work for Carbon and Cocoa apps (although not Classic).