Re: [Nautilus-list] properties window raising
- From: John Harper <jsh pixelslut com>
- To: Chris Heywood <psych primus com au>
- Cc: Havoc Pennington <hp redhat com>, Darin Adler <darin bentspoon com>, nautilus-list lists eazel com
- Subject: Re: [Nautilus-list] properties window raising
- Date: Tue, 21 Aug 2001 21:59:05 -0700
Chris Heywood writes:
|> > here (with sawfish 1.0 debian sid package) I see a quick flash then it
|> > (prop window) goes directly to the back without me doing anything. the
|> > properties window seems to have the focus (selected in task list) but it
|> > is hidden behind the other windows.
Despite what I said on the sawfish mailing list, this isn't actually a
sawfish bug. (Though it is my fault)
Nautilus has code to prevent windows being raised and focused from
clicks that initiate drags, this works partly though ICCCM trickery
(for the focus), and partly through sawfish private protocols (for the
raising). Unfortunately the raising part introduces a race condition
What happens is this:
1. you popup the icon context menu, this grabs the keyboard, and thus
takes the focus away from the nautilus window
2. you select the show properties item, focus is returned to the
nautilus window when the grab is released
3. sawfish notices this and tries to raise the window. Instead of
raising it immediately, it sends a _SAWFISH_WM_RAISE_WINDOW request to
Nautilus. Nautilus receives this and waits a short time to see if a
drag will be started
4. the show properties window is mapped, focused, and then raised by
sawfish
5. the nautilus window's timeout fires, no drag has been started, so it
raises itself, covering the properties window!
I'm not sure how to solve this. The race condition is avoided in the
focus case, since nautilus knows to send the timestamp it received with
the WM_FOCUS_WINDOW message back to the X server, which won't focus the
window if a more recent focus change has already happened
Unfortunately it's not possible to do the same thing with the X raise
window request. It would be possible to invent another sawfish specific
client message that allows the timestamp to be passed back to the
window manager, but I'm not sure how desirable this is. Another
possibility is to set the properties windows as a transient (though I
also see the problem briefly if I select `open in new window' from the
context menu)
John
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]