=== Top of the Swiki === Attachments ===

Squeak and VNC

There recently was some interest in connecting Squeak and VNC, e.g. on the Code Requests wish list and on the Postscript Support page.

About VNC


VNC is a protocol for remote display (and control) of an X-Windows / Win / Mac desktop. So why not use it to control your Squeak desktop as well? This would be ideal for

The software consists of two parts: the VNC server (keeps your desktop, and sends update information on request) and the viewer for displaying the desktop. VNC viewers are available for many platforms: (Mac, Windows, Unix, Java, even Win CE). Using the Java client, you can control your desktop using any Java-enabled Web-browser.

The server recognizes changes on the desktop and sends bitmaps with these changes to the client(s).

The home page for VNC is at http://www.uk.research.att.com/vnc/.

General Commentary


As a start, I have copied the relevant posts from Code Requests and Postscript Support. Feel free to add.
A really good discussion of How VNC Works is available at:

http://www.uk.research.att.com/vnc/howitworks.html

Does it make sense to have a "Squeak native" VNC server? Why not use the VNC servers that are already there for various platforms?

[Sept 14, 1999, BJP] Heh. Read on :) Several reasons, but the best I can think of is speed and reliability. When using Squeak with the WinVNC server, there are some performance and update problems. Of course, I don't really want the Windows screen anyway. I want the Squeak screen. Given what Squeak can know about it's own display (and that we have access to that code) there's room to do a lot of nice optimization. Plus, doing it in Squeak gives us consistency in the ports (e.g., the Mac VNC port tends to lag a bit).

[wish of Petr Novak (mailto:petr.novak@i.cz)] A VM, which does all user interaction through the VNC protocol. This would enable fast ports to platforms where the VNC viewer is already available (some PDA etc), or to run Squeak remotely where there is no support for this, with multiple concurrent sessions (such as Windows).
Why build this into the VM? Is'nt a VNC server listening to some port enough?
For remote display, it might be cool to slurp up VNC (http://www.uk.research.att.com/vnc/). If Squeak were a VNC server then we wouldn't even need Squeak on the client end to use it remotely. If it were a client as well, we could put remote desktops inside squeak windows!
[September 8, 1999 TBn]
Yep ... VNC is the right answer - it's free and with source code. Having a squeak server would also make it easy to interact with squeak on other remote systems. If we would have a VNC client morph it would also be easy to interact with motif, mac and windows desktops in squeak. I've downloaded the source for the Java viewer. It's very easy to understand - its only sending graphic bits via socket.
[September 8, 1999, BJP]
Re: VNC. There's also a very nice whiteish paper explaining the protocol. And yes, it seems like pretty much all you have to do is wire BitBlt up in the right way. I see the potential for lots of cool collaborative stuff, espeically if we have a "Squeak intelligent" viewer (in squeak). For example, there's no need to push the whole screen, one could downgrade the bit depth for faster update, you could have different projects pushed to different viewers, etc.
[Sept 11, 1999, LS]
VNC sounds cool, but not if all it does is send bitmaps around. Does it support commands like drawing lines and drawing text with a specified font? If not, then it unfortunately doesn't sound any better than the current XWindows Squeak port. Squeak on XWindows just is not pleasant to use remotely.

Additionally, don't forget about arranging for mouse and keyboard input to come back to the image....
[Sept 11, 1999, BJP]
More on the VNC digression. Yes, it's "just" sending bitmaps around, but it allows for security, encoding and partial update, and mouse and keyboard (and clipboard!) support. Plus, there are viewer and clients for everything (mac, Windows, unix, Java, even Wince!) It's very, very lightweight. It doesn't send line/text/other drawing commands.

But wait! This is good. Done right, it can replace/augment BitBLT, yes? After all, BitBlt "just" sends bitmaps around. But then one gets all the native Squeak drawing primatives free! Pen could write locally or remotely, or both.

It depends on what you're doing. I bet for many situations, its faster to just "draw once; copy everywhere".
[Sept 18, 1999, LS]
The current Unix port of Squeak uses X11, and it ships bitmaps around. It works fine on the local display, but it's absolutely abysmal when used over a 10MB network.

To compare, Netscape, which has some fairly complicated UI thingies, uses X command such as draw a line, drow a rectangle, and netscape runs just fine over 10MB ethernet.

So I don't think that just shipping bitmaps is such a great solution.

[Sept 14, 1999. BJP]
Further thoughts: Basically, it would be need to have multiple DisplayScreens, some local, some remote. Having different windows onto to different projects would be very neat. The difficulty, of course, is handling multiple streams of input. Perhaps MultiUser Squeak?

(Hey, c'mon. This started as a digression from the PostScript project...we now need a full blown digression from the VNC discussion :))


[Sept 18, 1999, LS]

Shipping the display around is relatively easy. The real complication is having multiple input devices.

So here's a proposal: have an abstract Terminal class, which keeps track of a display, allows you to input from a mouse and keyboard, and allows you to change the apperance of the correct mouse cursor. For the local case, Terminal would be trivial: just map to the current Display (or FormCanvas), the current Sensor, and use the default Cursor updating commands.

For the remote case, you could replace all these things with objects that talk over the network.

With such a scenario, the real trick is getting commands to do things like "self world sensor" instead of just "Sensor"....
[April 13, 2000, LS]
I've started implementing this VNC-like system. See Nebraska.