running metacity:
meh@wicket:~$ xprop | grep _NET_WM_STATE _NET_WM_STATE(ATOM) =
running kwin:
meh@wicket:~$ xprop | grep _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN
Not that I understood how this was supposed to work to begin with, but this really doesn't make any sense to me.
On 7/4/06, Elijah Newren newren@gmail.com wrote:
On 7/2/06, Vincent Povirk madewokherd+d41d@gmail.com wrote:
Some patches were committed to wine recently to make it use _NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to work in kwin but not metacity (I was using firefox as a test). In metacity, it appears wine recognizes that it needs to make a window fullscreen and send the appropriate message, but nothing happens (panels are still on top of firefox in fullscreen mode).
I've mentioned this on wine's bug (http://bugs.winehq.org/show_bug.cgi?id=3312), but I suspect it's probably caused by some quirk in metacity that wine triggers by doing some rather odd things itself. That's why I've CC'd the metacity-devel list (to which I and probably anyone on any wine mailing lists are not subscribed).
So, uh, metacity people, under what circumstances would metacity be likely to put a window that had sent the proper _NET_WM_STATE_ADD message for _NET_WM_STATE_FULLSCREEN behind panels?
If you have properly changed the fullscreen state as it sounds, the only case in which metacity ignores this hint is when the window doesn't have focus and is on the same xinerama as the window that does have focus (this is to allow the user to alt-tab to another window and do something without having the window they alt-tab to just remain covered up). So, if you can run xprop | grep _NET_WM_STATE and click on the relevant window and it shows "_NET_WM_STATE_FULLSCREEN" as one of the states and then focus that window and observe it to not be on top of all other windows (including panels), then it sounds like you've discovered a bug in Metacity. If so, I would be interested to learn how to reproduce so that I can fix it.
Thanks, Elijah