Slashdot Mirror
Making Mac OS X Work Like X Windows?
X Fiend asks: "Is it possible to configure Mac OS X's window manager to run in a client-server mode like X Windows? I'd like to use my (rather anemic) iBook as an X Terminal, with apps running on my (manly dual-processor) desktop machine, but I don't want to have to use X Windows to do it- I want to use Mac OS X's native window manager. Any ideas?"
The closest you'll get to this is using software like VNC, Apple Remote Desktop, or Timbuktu to display the desktop's screen on your laptop.
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
In theory, all IPC is done through Mach messages, whether the underlying transport is TCP/IP or shared memory.
In theory, you can intercept messages between two ports and run them through arbitrary filters.
Since the window server process is nothing but another port to Mach, you *should* be able to catch everything going to it, send it over the network and have it appear on another Window Server on another machine.
In practice there would be a lot of details to take care of like configuration and non-display. But the nature of Mach is that any IPC can be generalized to take place over any kind of network connection.
That's completely uninformative.
Apple Remote Desktop is a VNC or Timbuktu-like program, which pushes the (compressed) bitmap of a desktop to the client machine. While it can work for the situation the questioner asked about, it
(a) is not a truely native solution, in which the API calls are transmitted rather than the bitmap of the screen, and
(b) is geared towards education, where it can be used by a teacher to show a demonstration on a set of student computers.
It also costs $300.
NeXT's Display Postscript had the ability to run remotely, like X, but those hooks were abandoned when Apple converted the display model to Quartz/Display PDF.
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
That, of course, is the real answer. It is also no fun
/., really.
The fun comes in watching every karma-whore wax technical about different characteristics of the underlying technology that make it easy / difficult to implement feature X on system Y, while missing the original point entirely. Just part of the fun of reading
___
Cogito cogito, ergo cogito sum.
Sorry I was aggressive in my post. But your aggression to the asker of the question rankled me. The submitter has a point.
As for my points:
(a) Yes. Apple Remote Desktop is a bitmap-pusher, like VNC or Timbuktu. It does *not* hook into Quartz in the same manner that remote X hooks into X, or that RDP hooks into Window's GDI.
(b) Read about the product. It's not a protocol for sharing apps across different computers, although it could work that way. As I (admittedly awkwardly) said, it emphasizes a scenario in which a teacher has a program running on his or her computer, and that teacher's screen is "pushed" onto a bunch of student computers, so they can watch the teacher's demo.
And I'll elevate the price issue to
(c) it costs $300.
So while the poster may appreciate your link, Apple Remote Desktop is not a direct answer to his question, any more than a link to VNC or Timbuktu would be.
There remains a real issue here of the non-remoteness of the Quartz APIs, an issue that Apple really should try to deal with. Many, many people want them to re-implement this, after it was lost from NeXT.
(By the way, if you have an old copy of OS X Server 1.2 around, you CAN do remote display on that platform, since it still used Display Postscript instead of Aqua)
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
Point b) is also very valid because it details what the intended purpose of different technologies is. Whereas X allows you to load JUST an application, such as eterm, on the remote machine, ARD forces the entire server screen buffer to be loaded...in its own window (blech!). X also lets you log into the server as any user and run programs, regardless of which user is currently logged into the GUI. ARD forces you to use the current user, and takes the machine over.
mithras was right in his analysis of the technology. ARD is to be used in labs, large deployments, etc to manage multiple machines (install files, mass reboot, system status, monitoring, etc), but is hardly a client-server ideal setup like X.
I had heard somewhere that rumors persist of the hooks still existing in OS X, but the APIs are secret. That's not fact though. I WISH Apple would produce a system like that, but I fear they will not. It might also be possible that because of how Display PDF works (creating a PDF for each screen element, then compositing them together), it is not possible to merely send the screen draw APIs. Maybe?
But if you're like me, and you WANT this capability, Tell Apple!
here's a link for the only OS X VNC server that I know of:
http://www.redstonesoftware.com/osxvnc/
Other VNC servers and clients can be found at:
www.realvnc.com
It works, but you'd better be running a 100Mbps LAN with plenty of horsepower on both ends of the connection. OS X is a lotta GUI to be managing remotely.
I was under the impression - admittedly a glib one - that it's possible to send remote Aqua events using Applescript over any of the network layers.
...
It may be, but not for ARD.
I also was under the impression - mistakenly, since you've said ARD is a bitmap pusher - that ARD used this capability to reduce network clutter.
If only. It's a bitmap pusher, that's all.
The bitmap issue, of course, is key. VNC wins, hands-down - since ARD ain't free.
VNC is also MUCH more reliable and can easily be invoked (and shut down) from a remote shell.
If it came down to it, though, ARD will still get the job done - and may have the added advantage that with a fast network connection, ARD may one day be able to do such things as play Quicktime movies (albeit buffered) seamlessly
ARD is not suitable as an X replacement. For starters it only supports one client connection at a time. Secondly it freezes - often. No good having a remote admin tool if it doesnt work. Thirdly it's bandwidth intensive, as it's a bitmap pusher. Admittedly bandwidth is becoming less of an issue however the less you need to push around the faster you can do it.
Also, isn't ARD included with all 10.2 Server packages now?
No it isn't, but it should be.
ARD is a screen controller, nothing more. There is also the security aspect - if you are controlling a machine remotely, anyone who is physically able to can see what you are doing and take over at any time. For example - someone sees you log in as the admin, or perhaps root then unplugs the network cable to tinker with the box. This would not be possible with correctly configured X.
the multiple user GUI Aqua interface rumor has been running around for a while. most recently Mac OS Rumors has been reporting that it is something Apple is working on. MOSR recommends those who want to be able to use Aqua as if it were X-windows should contact Apple and make the request.
but to answer your question, there is NO way to do what you want short of taking over the desktop machine's screen. (or buying a new faster *book...)
Go to Versiontracker and search for VirtualDesktop. This software besides giving you virtual desktops (up to 100 in a 10 x 10 grid) also enables 'focus follows mouse' which is in essence sloppy focus and works pretty damn well...
try it you won't be dissapointed.
A fool throws a stone into a well and a thousand sages can not remove it.
The OSX Window manager can be made to start without the finder by writing a shell script that , in one file, starts the window manger and then starts an application like the terminal. If you go into the console from the login window with ">console" and login as root, you can then start this shell script and will be blessed thereafter to be able to use MAC OSX without the rather slow finder.
Why do I write this? This simply illustrates that Apple has done quite a lot in order to hide the window manager, and a lot of other functionality, in the normal view and it is very possible that there are indeed hidden hooks in the window manager to get it to work over a network, such as the ability to create a seperate window from another machine, not just pushing bitmaps around. The technology is certainly there, with Remote Objects in Cocoa. I also don't think it has that much to do with Quartz, as quartz is simply the drawing system and the window manager is the system that actually manages all created windows. Quartz simply composits and draws them. The fact that 10.1 had the hack of enabling one to enable window buffer compression lends some support to this theory. In theory one would simply have to know whether the window manager could send and receive window objects across the network, or if window objects were confined to the local machine.