Pasteboard ========== The quartz-wm window manager now handles all proxying between the OS X pasteboard and the X11 server's selections. It does this entirely lazily, i.e. nothing gets copied anywhere until the text is actually required for pasting. For X11 applications that support it, the UTF8 encoding is used. The scheme is something like this: NSPasteboard -> X11 ------------------- When X11 becomes active (i.e. has key focus) the window manager checks if text data is on the pasteboard (and that it didn't originate from X11). If so, it claims ownership of the PRIMARY and CLIPBOARD X11 server selections. Any subsequent requests from X11 clients for either of these selections will be directed to the window manager (until someone else claims them). It then fetches the data from the NSPasteboard, converts it to whatever format was requested, and sends it to the client in the normal manner. X11 CLIPBOARD -> NSPasteboard ----------------------------- When X11 goes inactive (i.e. another app, or an appkit window has focus), the wm queries the owner of the X server CLIPBOARD selection. If it's not owned by the window manager (i.e. already proxied), the wm declares to the pasteboard that it has text available for pasting. Native clients wanting to paste will then result in AppKit calling back to the window manager's selection controller asking for the data. It then attempts to fetch it from the X11 client owning the CLIPBOARD selection, converts it to an NSString and writes it onto the pasteboard. X11 PRIMARY -> NSPasteboard --------------------------- Finally, when an X11 window is active, selecting the "Copy" item from the "Edit" menu on the main menubar tells the window manager to proxy the PRIMARY selection onto the NSPasteboard. I think this covers the largest set of use-cases, without having any undesirable behaviour. Since it proxies both CLIPBOARD and PRIMARY, almost all X clients will be able to both copy and paste to native applications (except for those which solely use CUT_BUFFER's, which should be extremely rare.) The code to do all this is almost entirely self-contained, and uses no private APIs. So for people who don't want to use our window manager, it would be possible to provide a standalone proxying daemon. Native Fonts ============ XFree 4.2 seems to use Xft1, so we're not using the fontconfig stuff yet, but the old Xft font configuration system (should be ok for now, since it's transparent to applications) The changes I needed to make were: 1. patch freetype sources in X distribution to turn on ftmac.c, which handles loading mac-style font files (I had to fix the code that converts input paths to FSSpec's) I had to turn off the bytecode interpreter, since the copy of freetype that XFree ship has it enabled. (I also turned off all hinting by Xft, just to see if it would be acceptable, I think it is, though the Xft lcd rendering code seems to cause much more color fringing on some fonts when hinting is disabled) 2. patch X configuration to build libfreetype as a static library and link it directly into the dynamic libXft (to avoid symbol conflicts with the other libfreetype I have installed) 3. edited /etc/X11/XftConfig adding: dir "/System/Library/Fonts" dir "/Library/Fonts" to the top of the file. 4. ran xftcache as root to generate the XftCache files in each font directory 5. added the entry "Xft.rgba = rgb" to my X resource database to turn on subpixel rendering