Re: X11/Spaces thinks X11 windows are overlapping on different Spaces
Re: X11/Spaces thinks X11 windows are overlapping on different Spaces
- Subject: Re: X11/Spaces thinks X11 windows are overlapping on different Spaces
- From: Ben Byer <email@hidden>
- Date: Thu, 08 Nov 2007 02:51:16 -0800
On Nov 8, 2007, at 2:30 AM, Jeremy Huddleston wrote:
On Nov 8, 2007, at 1:16 AM, Greg Parker wrote:
Most window managers wrap ("reparent") each client window inside
another window created by the window manager itself. This wrapper
window is where the window manager draws its window decorations
(title bar, close box, etc). Your program's first query is catching
its own windows before the WM reparents them.
Ah, that makes sense. Thanks. I've never dealt with X11 directly
like this before. Pretty cool, thanks for the info.
Anyways, as my previous post indicates, your theory seems to be
correct. Now we just need to see why Xquartz isn't updating its
window stack correctly.
I still have plenty of emails from yesterday to address, but I've been
trying to clear some other stuff out of my queue. This caught my eye
enough that I wanted to address it immediately:
I draw your attention to http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=blob;h=113a7d22e64f21130d95b913174242e7d11dfaf4;hb=774920637a12398918299847225bc982a694b82e;f=hw/darwin/quartz/quartz.c#l344
Half of the entire list of bugs we're dealing with probably come down
to that one function (DarwinModeProcessEvents):
* The patch I dropped from the old X11.app used kXDarwinBringAllToFront
* The Spaces bugs came from not having implemented kXDarwinWindowState
and kXDarwinWindowMoved -- specifically, we were getting the
WindowMoved notifications from libXplugin but were ignoring them. It
might be that we get an kXDarwinWindowState notification about the
restacking, but we're not correctly handling it.
* We're probably not handling kXDarwinDisplayChanged correctly, which
is why people see no config change when they plug an external monitor in
* We need to be dropping our modifier state when we get
kXDarwinDeactivate, and there's code to do that, but it's not working,
which is causing the "stuck modifier keys" issue
All of these involve data that goes through that "pipe" of events --
sometimes it's present in the code that's sending the events (but
sending them incorrectly) -- e.g. hw/darwin/quartz/xpr/xprScreen.c
eventHandler().
Sometimes it's in the code that gets called by that switch() statement
-- e.g. RootlessNativeWindowStateChanged()
Just something to chew on, for those so inclined. :)
--
Ben Byer
CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden