[Xquartz-dev] fb / rootless crash bugs

[Greg Parker]

On Dec 5, 2007, at 11:36 AM, Nathaniel Gray wrote:
> On Dec 4, 2007 4:36 PM, Greg Parker <gparker at apple.com> wrote:
>>
>> I took a quick look at Composite. It looks like it was designed to
>> work inside a window manager. I'm not sure that makes sense in our
>> environment. We could make quartz-wm also in charge of the Mac  
>> windows
>> via Composite, but that might leave other window managers out in the
>> cold. One alternative might be to use the Composite code paths in the
>> server, without using the Composite extension directly.
>
> I'm certainly not an expert, but it does seem to me that Composite is
> a very promising approach.  It basically turns the X server into a
> rendering library for window contents instead of a full desktop window
> system.  This is exactly what we want!  Just have it render to the
> backing stores of the windows of a Cocoa application -- native window
> management for free!  I'm oversimplifying, I'm sure, but it seems like
> an attractive option.
>
> As for alternative window managers, well, other window managers are
> already out in the cold.  They can't interleave windows with native
> windows and generally don't behave naturally on OS X.  But this is not
> an either-or thing -- other window managers can use the traditional
> code paths while OpenQuartzWM (the shiny new open-source version of
> quartz-wm ;^) can use the Composite path.

Other WMs may behave unnaturally, but they *do* work. I bet you'd hear  
a lot of screaming if we threatened to take them away.

We really don't want to keep both Rootless and something that replaces  
it; that's just asking for trouble down the road when one side doesn't  
get enough testing.


> Another thought worth considering -- should we perhaps be writing a
> composite manager *instead* of (or in addition to) a window manager?
> Existing window managers are OK at handling X windows, they just don't
> know about compositing with the other Aqua windows on the OS X
> desktop.  Maybe writing a native compositer could solve that.

That's the part I'm not sure about. I don't know whether using a  
composite-unaware window manager together with a composite manager  
works in practice. I also don't know what happens if you try to use a  
window manager that *does* use composite together with a composite  
manager (which is what happens if we use composite in the server for  
windows and a user uses some-random-wm on top). They might conflict  
while trying to take over control of top-level windows.


-- 
Greg Parker     gparker at apple.com     Runtime Wrangler