GNOME Bugzilla – Bug 338246
GSThemeWindow unsets the fullscreen and keep_above flags on the screensaver window
Last modified: 2006-04-24 17:26:35 UTC
Under compiz, screensaver windows sometimes end up under the panel rather than over it. I eventually tracked this down to the fact that the screensaver modules were unintentionally clearing the "fullscreen" and "keep_above" flags on the window; GSThemeWindow subclasses GtkWindow but overrides "realize" to just use the existing foreign window. But it doesn't override "map" (and can't easily without messing up the GtkWindow object's internal state), so gtk_window_map() still gets run when the saver gtk_window_show()s the GSThemeWindow. And it seems that no one called gtk_window_fullscreen() or gtk_window_set_keep_above() on the GSThemeWindow, so it removes those bits from its wmstate. Metacity apparently doesn't notice/care about this, but under compiz, that causes it to be restacked in the new correct location (under the panel). The attached patch fixes this by calling all of the same GtkWindow methods in GSThemeWindow as it does in gs-window-x11.c. But that seems like a kludge. Shouldn't it be using GtkSocket/GtkPlug here rather than having a single X Window object be represented by two GtkWindows in two different processes?
Created attachment 63322 [details] [review] patch
Hmm, that probably means that it is losing its window type of GTK_WINDOW_POPUP (ie. override-redirect) right? I thought about using socket/plug once upon a time but I wasn't sure it would work well with "legacy" themes (aka xscreensaver hacks). Also it might much to require all hacks to be implemented as a plug. There might be issues with input focus and events too. Not sure.
Created attachment 63329 [details] [review] alternate patch Does this work too?
Nope, that doesn't help, because override-redirectness doesn't affect stacking order. (Also, I think the value you pass there doesn't affect anything in the running-as-a-screensaver case, because it only gets looked at by gtk_window_realize, which you're bypassing, unlike the other properties, which are looked at by gtk_window_map.) I hadn't realized that the way you're handling screensavers was done for compatibility with xscreensaver. (I guess the "XSCREENSAVER_WINDOW" environment variable should have been a giveaway...) Maybe the solution is to have GSThemeWindow not actually be a subclass of GtkWindow then.
But override-redirect windows should bypass the window manager, no? And keepabove and fullscreen are only hints to the window manager, right? But it looks like you're right about POPUP not being used in this case.
Ah. gs-window-x11.c calls gtk_window_set_decorated (GTK_WINDOW (window), FALSE), and compiz had a bug where it was assuming that if you set the motif window decoration hint on a window, it must not be override-redirect. So compiz doesn't need the patch above any more, although it still seems like gnome-screensaver is broken (in that it's setting hints that the wm ought to be ignoring anyway, and then immediately afterward removing them...)
Oh OK - I'm glad we understand what's happening now. The set_decorated call is just left over from when we weren't override-redirect :) I agree that the way we're doing it is a little strange. This ThemeWindow is just meant to be a convenience wrapper used by the three theme engines we ship together with g-s. So, it can and should be changed to be sensible before it gets wider use.
Committed to HEAD. Thanks.