On Dec 1, 2007, at 4:28 PM, Kyle McKay wrote:
Ben,
I have been using the latest versions of the Xorg X11 for 10.5.x that you have posted at <http://people.freedesktop.org/~bbyer/x11app/
. They have resolved a whole bunch of problems -- wireshark works for me now, kdevelop runs without anymore unreadable garbage in scrolling windows and the yellow cursor problem is gone. Thank you for posting these.
Hopefully fullscreen will start working someday soon as well.
But the subject of this post is Xquartz, the Dock and XDMCP. I am now successfully running Xquartz directly from a shell prompt like this:
Xquartz :1 -query remote.host.name -from ppp.if.address +xinerama - once
(where remote.host.name is the host I tested with and ppp.if.address is the IPv4 address of my end of the VPN ppp connection I brought up so I could test).
Works fine. An icon shows up in the Dock as soon as I start Xquartz. I do have to click on it or Command-Tab to it to bring it forward at which point I can log in to the remote host via its login dialog.
So what you need to do to make this work is add a 'plst' 0 resource to Xquartz. (See <http://developer.apple.com/technotes/tn/ tn2013.html> for info about this.)
Awesome! Does this end up using the actual X11.app icon, or just the generic "exec" icon? I have another solution from the Dock team, that involves adding this code to X11ApplicationMain: + ProcessSerialNumber psn = { 0, kCurrentProcess }; + fprintf(stderr, "Calling TransformProcessType\n"); + TransformProcessType(&psn, kProcessTransformToForegroundApplication); + SetFrontProcess(&psn); It produces a dock icon (although only the generic one), but when I actually try to run xterm, as soon as I click on it, it crashes here: Thread 1 Crashed: 0 Xquartz 0x0002799d RootlessNativeWindowMoved + 16 (rootlessWindow.c:144) 1 Xquartz 0x000186ee DarwinModeProcessEvent + 798 (quartz.c:471) 2 Xquartz 0x000057ce ProcessInputEvents + 1930 (darwinEvents.c:409) 3 Xquartz 0x0007ddcf Dispatch + 117 4 Xquartz 0x000995e5 main + 1921 5 Xquartz 0x00019f24 server_thread + 59 6 libSystem.B.dylib 0x9672b075 _pthread_start + 321 7 libSystem.B.dylib 0x9672af32 thread_start + 34 It sounds like your solution gives a better result (and without crashing!), but Apple is trying to deprecate resource forks in general and I'm not sure I'd actually be able to ship a fix that required adding a resource fork. :( -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer