Many of you may be wondering what OroborOSX offers that Apple's X11 doesn't.
Good question.
When Apple first introduced their version of X11 I put together a comparison chart. This latest chart has since been updated to include the latest v0.9 final release...
Feature Apple X11 OroborOSX Comments/Notes ------- --------- --------- -------------- Fast drawing YES v0.9 v0.9 final uses Apple's X plugin library Hardware OpenGL YES v0.9 Though Apple's slightly faster on >OSX10.2.3 Smooth dragging YES Better in 0.9 XDarwin's 'shaped' windows need some clever trick Fast/smooth resize YES Better in 0.9 As above (Orob. faster than plain XDarwin 'shaped') Fast launching YES Better in 0.9 (Orob. waits for XDarwin -why is it so long...?!) Smooth font rendering YES v0.9 (Not really clear on how this all works...?) Zoom window honours Dock YES v0.9 (Wish I'd got around to fixing this sooner!) Deals with screen changes Mostly Mostly (X11 really has trouble with this concept...) Captures cmd shortcuts YES Special in 0.9 v0.9 final has new cmd-key shortcut mode Simple X11 app launching YES YES Launch menu in Orob. needs better GUI (offers...?) Copy/Paste to/from Aqua YES YES (For some reason, ppl overlook this in XDarwin) First click only raises YES (quartz-wm) YES (Some ppl don't like it -has rollover 'issue') Window interleaving YES (quartz-wm?) YES Does Apple's X11 interleave under other WMs? Minimise-to-Dock YES (quartz-wm) YES (Presumably, only quartz-wm can min-to-dock) Windows listed in menu YES (quartz-wm) YES Orob. also has groups listed, and shows window state Alternative minimise Via Other WMs YES (Useful with >1 screen -Dock is only on main screen) Good placement on >1 scrn NO YES Orob. over-rides bad window placement for >1 screen Windowshading NO YES (Option to flip min. and Wshade in Orob. soon..?) Choice of DISPLAY number NO? YES (Done in Orob. via XDarwin's prefs) Works with VirtualDesktop NO YES (Since Orob. v0.8.5 and CVD 2.0) Translucent windows NO YES (On a per-window basis in Orob.) Doesn't use xinitrc NO YES Leaves xinitrc for parallel/standard X11 sessions Drag/resize in background NO YES Orob. middle-button, or cmd-key if mod1 is Meta_L Background paste Not done right YES quartz-wm raises window on middle-click -confusing Choice of non-Aqua look Via Other WMs YES Lose some functionality if not using quartz-wm Auto-focus Via Other WMs YES (On a per-window basis in Orob.) Auto-raise Via Other WMs YES (On a per-window basis in Orob.) Auto-lower Maybe Other WMs? YES (As above - nice for 'toolbars', eg. in gimp...) Non-interfering resize NO (in quartz-wm) YES (Orob. themable, so can easily look like quartz-wm) Bottom drag bar NO (in quartz-wm) YES (Again, could be changed in Orob. via theming) Frameless window option NO YES (Some windows just don't benefit from frame!) Drag-n-drop to X11 apps NO YES (New for Orob. v0.8.5 -'Finder integration') Launched apps see ssh-agent NO YES Orob. Launch items find it automatically Grouping of X11 windows NO YES Needs more work in Orob. to distinguish X11 apps Hiding of window groups NO YES (So experience appears a bit more 'Mac-like') Cycling of window groups NO YES (As above - a bit like cmd-tab...) Works with OSX10.3 YES YES Versions before 0.9 final need keyboards folder Works with OSX10.2 Only old betas YES (Why do Apple want to prevent access to betas?) Works with OSX10.1 NO YES (May be a bit of a killer for some... :-( ) Works with OSX10.0 NO YES (not 0.9) (But VirtualDesktop won't...) Virtual Desktop/Wkspace Via Other WMs Not built-in (CodeTek VirtualDesktop gives OSX-wide with Orob.)
Obviously, speed is the biggest factor in favour of Apple's X11. OroborOSX v0.9 mostly nulls that advantage, since it uses Apple's own X11 plugin library to accelerate certain drawing operations (i.e. it ends up just about the same speed). The main area it can't quite keep up is with window resizing - largely to do with the way XDarwin handles 'non-opaque' shaped windows. Also Apple's X11 has 'GL Direct Rendering' (gains a few percent in frame-rate) - I guess Apple can 'hook into' the guts of their window server in a way nobody else can...
I suspect that many of the features offered by OroborOSX may well not improve the environment over that provided by Apple's X11 (with quartz-wm) for a considerable number of users (most likely those who tend to use only one or two complex X11 apps, alongside simple one-window terminals/editors, etc).
However, those who concurrently run several multi-window X11 apps, such as gimp and OpenOffice, will probably benefit from the window grouping available in OroborOSX, as well as the compatibility with CodeTek VirtualDesktop, and perhaps also the 'Finder integration' (drag-and-drop of files routed to X11 apps) - if any of these features are important to you then stick with OroborOSX until Apple's X11 starts to catch up (which I've no doubt it will in many areas...)
Having said that, it does seem to be quite possible to run both Apple's X Server and OroborOSX concurrently - simply by giving a non-zero display number in XDarwin's prefs (and assuming you have a decent enough machine to cope with two X servers on top of OSX)...
From my own testing, if you install Apple's X11 *over* XFree86, then even XDarwin.app still works fine. If you then change XDarwin's display (to "1", say) then relauch XDarwin or OroborOSX, as well as Apple's X11 (which uses display zero), you can pick and choose which X11 environment to use for different X11 apps. (Simply have DISPLAY as :0.0 for Apple's X11, and :1.0 for XDarwin -you can even have three X servers running: Apple's X11, OroborOSX, and standard XDarwin, on displays :0 to :2).
On a completely different note, I am glad to see 'Accept First Click' (as I called it in OroborOSX) is not the default behaviour in Apple's X11 (contrary to what I originally thought) - it's something I tried to ensure for OroborOSX, despite it being the 'norm' for X11 behaviour (and a number of people wanting it that way on the Mac too). It's especially good to see, since it appeared like something of a trend for Apple to move away from the original Mac interface where a click in a non-active window only brings it in front (except for a few special cases, such as selection of an object, as in Finder icons) - controls of Cocoa apps have this 'click-through' behaviour, whereas Carbon apps generally don't (they 'dim' instead). I often wonder why an extra click is such a hardship, when compared with the possibly disastrous effects of a misplaced 'click-through'... (Of course, as I mention in the list above, there is currently a major 'aesthetic' inconsistency in quartz-wm (fixed in OroborOSX v0.9), with regard to 'rollover' effects of controls etc. in X11 windows - I spent a long time trying to overcome this, and I finally got it going for v0.9.)
Of course, having 'first-click-only-raises' as the standard for *all* X11 windows can cause problems (which is why OroborOSX has options for 'Accept First Click', amongst other additions like 'Auto-Focus', 'Auto-Raise' and 'Auto-Lower' - there's also the currently inactive 'Floating Palette' property, which I never got around to implementing...) - no doubt Apple will add new options and workarounds for dealing with these issues in later versions of their X11.
Anyway, I Hope that's a useful overview!
Adrian