[Xquartz-dev] fb / rootless crash bugs
gparker at apple.com
Wed Dec 5 14:29:21 PST 2007
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
>> 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
More information about the Xquartz-dev