wine's fullscreen code has no effect on metacity
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? -- Vincent Povirk
On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote:
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?
Run metacity from the command line so you can see what it prints; metacity helpfully outputs warnings when applications violate the specs or do something weird. Maybe we can find out what's going on there. thanks -mike
I've tried that; it didn't work in this case. :/ On 7/4/06, Mike Hearn <mike(a)plan99.net> wrote:
On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote:
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?
Run metacity from the command line so you can see what it prints; metacity helpfully outputs warnings when applications violate the specs or do something weird. Maybe we can find out what's going on there.
thanks -mike
-- Vincent Povirk
On 7/2/06, Vincent Povirk <madewokherd+d41d(a)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
running metacity: meh(a)wicket:~$ xprop | grep _NET_WM_STATE _NET_WM_STATE(ATOM) = running kwin: meh(a)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(a)gmail.com> wrote:
On 7/2/06, Vincent Povirk <madewokherd+d41d(a)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
-- Vincent Povirk
On 7/4/06, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote:
running metacity:
meh(a)wicket:~$ xprop | grep _NET_WM_STATE _NET_WM_STATE(ATOM) =
running kwin:
meh(a)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.
Yeah, that looks really odd. That alone almost certainly means there's either a bug in KWin, metacity, or the EWMH. Could you try something for me to see if we can narrow down the cause? There's a special keybinding in Gnome, disabled by default, for manually setting windows to fullscreen mode. Could you run gnome-keybinding-properties, find the "Toggle fullscreen mode" item in the list, click on it, press some special key combo (e.g. Alt-F11), then focus your window in question, and press that key combo? That should make the window fullscreen and place it on top. If you could check the xprop thing again at that point just to verify the _NET_WM_STATE, that would also help. After we know that, we can try seeing if you're setting the state in a weird way that KWin accepts but other WMs don't, or are setting it in a valid but slightly different way that Metacity should accept but doesn't, or if Metacity is doing something else weird. Cheers, Elijah
I've enabled that key combination, and I can now make gedit fullscreen with alt+f11 so I think that's working properly (this is nifty; wonder how I missed it..). Pressing alt+f11 when windows firefox thinks it's in fullscreen mode has no effect. xprop shows no _NET_WM_STATE. However, it does work (sort of) if I press it when firefox is not in fullscreen mode, except that I can see part of the bottom panel (but can't interact with it; I assume it's really firefox's window there but firefox hasn't drawn anything). xprop does show _NET_WM_STATE_FULLSCREEN when I do that. I'm not aware of anything different about how wine sets fullscreen from other programs that I know work with metacity (I've compared the source code and as far as I can tell it's identical, unless wine is doing something else I'm not aware of).
Yeah, that looks really odd. That alone almost certainly means there's either a bug in KWin, metacity, or the EWMH. Could you try something for me to see if we can narrow down the cause? There's a special keybinding in Gnome, disabled by default, for manually setting windows to fullscreen mode. Could you run gnome-keybinding-properties, find the "Toggle fullscreen mode" item in the list, click on it, press some special key combo (e.g. Alt-F11), then focus your window in question, and press that key combo? That should make the window fullscreen and place it on top. If you could check the xprop thing again at that point just to verify the _NET_WM_STATE, that would also help.
After we know that, we can try seeing if you're setting the state in a weird way that KWin accepts but other WMs don't, or are setting it in a valid but slightly different way that Metacity should accept but doesn't, or if Metacity is doing something else weird.
Cheers, Elijah
-- Vincent Povirk
On 7/4/06, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote:
I've enabled that key combination, and I can now make gedit fullscreen with alt+f11 so I think that's working properly (this is nifty; wonder how I missed it..).
Pressing alt+f11 when windows firefox thinks it's in fullscreen mode has no effect. xprop shows no _NET_WM_STATE.
What does "windows firefox thinks it's in fullscreen mode" mean? Does the application try to manually resize itself in addition to sending the state change messages to the root window (perhaps as a workaround for WMs not supporting the _NET_WM_STATE stuff)? Or is there some other notification that the window is attempting to be in fullscreen mode? How are you making firefox try to enter fullscreen mode? (F11?)
However, it does work (sort of) if I press it when firefox is not in fullscreen mode, except that I can see part of the bottom panel (but can't interact with it; I assume it's really firefox's window there but firefox hasn't drawn anything). xprop does show _NET_WM_STATE_FULLSCREEN when I do that.
You see part of the bottom panel, but not the whole thing and you can't interact with any of it? Sounds like an application bug where Metacity has resized and placed the window on top but the app just hasn't updated from expose events. You could verify by e.g. running sleep 5; xprop | less in a terminal, switching to firefox during the sleep and putting it in fullscreen mode, then after the sleep clicking in the area where you see part of the bottom panel. xprop lists all kinds of crap, but the WM_CLASS or WM_NAME (both near the end) are usually pretty good ways to verify which application you clicked on. Anyway, it appears that the window does actually get placed into fullscreen mode given your comments, which means that we should look closer at the actual setting of the hint from wine. Could you point to the relevant code? Alternatively, I can point you to the source code in metacity. The Alt-f11 keybinding I had you set up is handled in metacity/src/keybindings.c:handle_toggle_fullscreen(). Messages from apps to add/remove/toggle these state properties are handled in metacity/src/window.c:meta_window_client_message() you'll want to search for "fullscreen" within that function as many other states are handled in that function as well. One other pointer that may assist you in debugging; you can use the command xprop -root | grep ^_NET_CLIENT_LIST_STACKING together with commands like xprop -id 0x22eb54c | grep WM_CLASS (substituting appropriate window ids from the first command) in order to figure out how your WM has stacked the windows.
What does "windows firefox thinks it's in fullscreen mode" mean? Does the application try to manually resize itself in addition to sending the state change messages to the root window (perhaps as a workaround for WMs not supporting the _NET_WM_STATE stuff)? Or is there some other notification that the window is attempting to be in fullscreen mode? Windows does not have a fullscreen mode. In Windows, windows that are Always on Top are on top of panels. Windows applications enter "fullscreen mode" by positioning themselves take up the whole screen and being always on top (actually, now I'm not so sure they have to be always on top; I'm only basing that on my experience as a Windows user).
When the size of a window or the screen resolution changes, Wine marks windows whose client area covers the whole screen as fullscreen. This is done in the update_fullscreen_state function in this file: http://cvs.winehq.org/cvsweb/wine/dlls/winex11.drv/winpos.c?rev=1.5&content-...
How are you making firefox try to enter fullscreen mode? (F11?)
Yep.
You see part of the bottom panel, but not the whole thing and you can't interact with any of it? Sounds like an application bug where Metacity has resized and placed the window on top but the app just hasn't updated from expose events. You could verify by e.g. running sleep 5; xprop | less in a terminal, switching to firefox during the sleep and putting it in fullscreen mode, then after the sleep clicking in the area where you see part of the bottom panel. xprop lists all kinds of crap, but the WM_CLASS or WM_NAME (both near the end) are usually pretty good ways to verify which application you clicked on.
That issue is with Alt+F11 (metacity forcing fullscreen mode), and it's not really as important, since Windows can't do anything like that.
Alternatively, I can point you to the source code in metacity. The Alt-f11 keybinding I had you set up is handled in metacity/src/keybindings.c:handle_toggle_fullscreen(). Messages from apps to add/remove/toggle these state properties are handled in metacity/src/window.c:meta_window_client_message() you'll want to search for "fullscreen" within that function as many other states are handled in that function as well.
I'll look at that when I have a chance (even though I'm not really an expert on this stuff), thanks. -- Vincent Povirk
Looking through the code made me notice the meta_verbose function and then the METACITY_VERBOSE environment variable. I set that and logged an attempt to fullscreen and then unfullscreen firefox. I can send the whole log if it might be helpful, but here's what stood out for me. Before firefox attempts to set the fullscreen hint, I see this: GEOMETRY: Updating WM_NORMAL_HINTS for 0x2e00010 (Mozilla Fi) GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets max size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets gravity 10 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) fullscreen = 0 not resizable, maximizable = 0 fullscreenable = 0 min size 1280x1024 max size 1280x1024 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) decorated = 1 border_only = 0 has_close = 1 has_minimize = 1 has_maximize = 0 has_move = 1 has_shade = 1 skip_taskbar = 0 skip_pager = 0 fullscreenable = 0? What? And before it tries to unset the fullscreen hint, I see this: GEOMETRY: Updating WM_NORMAL_HINTS for 0x2e00010 (Mozilla Fi) GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min width to 0, which makes no sense GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min height to 0, which makes no sense GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets gravity 10 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) fullscreen = 0 not resizable, maximizable = 1 fullscreenable = 1 min size 1x1 max size 2147483647x2147483647 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) decorated = 1 border_only = 0 has_close = 1 has_minimize = 1 has_maximize = 1 has_move = 1 has_shade = 1 skip_taskbar = 0 skip_pager = 0 What does "fullscreenable" mean, and is it possible that that's related to the problem? -- Vincent Povirk
Look at src/window.c:recalc_window_features() for possible reasons metacity decided to disable fullscreenability. In this case it looks pretty clear though - the firefox window isn't resizable, metacity disables fullscreen in that case unless the window size is equal to the screen size and the window is not decorated. It looks like 1280x1024 could be your screen size, so my guess is that the window has a frame on it. I don't really know why the !window->decorated is in the check in recalc_window_features but Elijah may well. This would explain why wine fullscreening works sometimes, it probably works when the window is a) full screen size and b) also disables the window decorations. Fullscreen mode would remove the decorations anyhow though, is why I don't know why metacity checks this. Havoc Vincent Povirk wrote:
Looking through the code made me notice the meta_verbose function and then the METACITY_VERBOSE environment variable. I set that and logged an attempt to fullscreen and then unfullscreen firefox. I can send the whole log if it might be helpful, but here's what stood out for me.
Before firefox attempts to set the fullscreen hint, I see this:
GEOMETRY: Updating WM_NORMAL_HINTS for 0x2e00010 (Mozilla Fi) GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets min size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets max size 1280 x 1024 GEOMETRY: Window 0x2e00010 (Mozilla Fi) sets gravity 10 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) fullscreen = 0 not resizable, maximizable = 0 fullscreenable = 0 min size 1280x1024 max size 1280x1024 WINDOW_OPS: Window 0x2e00010 (Mozilla Fi) decorated = 1 border_only = 0 has_close = 1 has_minimize = 1 has_maximize = 0 has_move = 1 has_shade = 1 skip_taskbar = 0 skip_pager = 0
On 7/6/06, Havoc Pennington <hp(a)redhat.com> wrote:
Look at src/window.c:recalc_window_features() for possible reasons metacity decided to disable fullscreenability.
In this case it looks pretty clear though - the firefox window isn't resizable, metacity disables fullscreen in that case unless the window size is equal to the screen size and the window is not decorated.
It looks like 1280x1024 could be your screen size, so my guess is that the window has a frame on it.
I don't really know why the !window->decorated is in the check in recalc_window_features but Elijah may well.
Nope, but I found this: 2002-08-15 Havoc Pennington <hp(a)pobox.com> * src/window.c (recalc_window_features): leave has_fullscreen_func set to TRUE if the window is screen sized and undecorated, even if the window isn't resizable. idea from Christian - Manny Calavera - Neumair You didn't state a bug number or anything, so no more details appear to be available. I also don't see why the decoration check is there, but the fact that it is would explain why subsequent "fullscreen me" messages from the app would be ignored. As Rob pointed out, there are also some heuristics in src/stack.c (see window_is_fullscreen_size()) to try to treat certain windows as fullscreen despite their incorrect methods at attempting to fullscreen themselves (such as what these windows apps with wine are apparently doing). These heuristics, at least at first glance, also look broken to me in the case of windows with decorations since constraints will force the client area of the window away from the upper left corner of the workarea. (This appears to be true for both the old metacity-2.12.x version and the current one)
"Havoc Pennington" <hp(a)redhat.com> wrote:
Look at src/window.c:recalc_window_features() for possible reasons metacity decided to disable fullscreenability.
In this case it looks pretty clear though - the firefox window isn't resizable, metacity disables fullscreen in that case unless the window size is equal to the screen size and the window is not decorated.
It looks like 1280x1024 could be your screen size, so my guess is that the window has a frame on it.
I don't really know why the !window->decorated is in the check in recalc_window_features but Elijah may well.
This would explain why wine fullscreening works sometimes, it probably works when the window is a) full screen size and b) also disables the window decorations.
Fullscreen mode would remove the decorations anyhow though, is why I don't know why metacity checks this.
From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
"_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. Additionally the Window Manager is responsible for restoring the original geometry after a switch from fullscreen back to normal window." As I understand the above quote it's the WM's responsibility on application's request to remove window decorations and resize a window to fill the screen, then restore its previous state when switching from a fullscreen state. So, all the checks metacity does for window decorations and window size are contradicting the spec IMO. Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically. -- Dmitry.
On 7/6/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
"_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. Additionally the Window Manager is responsible for restoring the original geometry after a switch from fullscreen back to normal window."
As I understand the above quote it's the WM's responsibility on application's request to remove window decorations and resize a window to fill the screen, then restore its previous state when switching from a fullscreen state.
Yes, if it ever switches to a fullscreen state.
So, all the checks metacity does for window decorations and window size are contradicting the spec IMO.
No, the window would have to be in the fullscreen state in order for checks on window decorations or window size to even have the possibility of breaking the spec. Those checks in src/stack.c were basically meant as a workaround to help legacy applications who don't correctly put themselves into fullscreen mode still get into that mode. Yes, the checks appeared buggy (and we will fix them if I can find some time to verify), but it shouldn't adversely affect any well behaving application.
Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically.
Feel free to point to anywhere in the ICCCM or EWMH that says so. Of course apps can be resized programmatically -- because the not-resizable hints can be modified programmatically. I disagree with allowing the app or other utilities to modify the size of an unresizable window unless the unresizable'ness is first modified. My $0.02, Elijah
"Elijah Newren" <newren(a)gmail.com> wrote:
Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically.
Feel free to point to anywhere in the ICCCM or EWMH that says so. Of course apps can be resized programmatically -- because the not-resizable hints can be modified programmatically. I disagree with allowing the app or other utilities to modify the size of an unresizable window unless the unresizable'ness is first modified.
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507474 "A list of atoms indicating *user* operations that the Window Manager supports for this window". -- Dmitry.
Dmitry Timoshkov wrote:
So, all the checks metacity does for window decorations and window size are contradicting the spec IMO.
Both the ICCCM and EWMH are specs for "hints" - they have a big "any of these hints may be ignored" disclaimer attached. In practice, categorically ignoring (or misinterpreting) the hints would result in an unusable WM, but so would blindly following them all. Most real window managers are pretty complex with lots of special cases and "magic" to support legacy apps or whatever. We used to have a "strict spec compliance"/"disable workarounds" mode in metacity and it was unusable unless you ran GTK/Qt apps exclusively, pretty much. While my memory is too fuzzy to point to specific bugs, I'd be willing to bet that I added more than one little hack inspired by WINE, which used to be unaware of EWMH and perhaps a bit sketchier than Qt/GTK on the older ICCCM behaviors too. Anyway, few WM bugs can be resolved by appeal to specifications alone...
Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically.
In practice the geometry hints are widely treated as strict constraints honored for all configure requests from any source. Most WMs ignore them at least sometimes though, e.g. ignoring the size increments when maximizing is a common choice. If nothing else, in modern desktops it's quite hard to tell which configure requests are user-originated and which are not. Havoc
"Havoc Pennington" <hp(a)redhat.com> wrote:
We used to have a "strict spec compliance"/"disable workarounds" mode in metacity and it was unusable unless you ran GTK/Qt apps exclusively, pretty much.
While my memory is too fuzzy to point to specific bugs, I'd be willing to bet that I added more than one little hack inspired by WINE, which used to be unaware of EWMH and perhaps a bit sketchier than Qt/GTK on the older ICCCM behaviors too.
Anyway, few WM bugs can be resolved by appeal to specifications alone...
Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and doesn't in GNOME :-) If you could point out what Wine is doing in wrong way I'm all ears.
Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically.
In practice the geometry hints are widely treated as strict constraints honored for all configure requests from any source. Most WMs ignore them at least sometimes though, e.g. ignoring the size increments when maximizing is a common choice.
If nothing else, in modern desktops it's quite hard to tell which configure requests are user-originated and which are not.
That one is simple: if a request is being originated by a user interaction it's a user's request and might be restricted; if it's a result of an API call it's done programmatically and should be executed by all means. -- Dmitry.
Dmitry Timoshkov wrote:
Anyway, few WM bugs can be resolved by appeal to specifications alone...
Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and doesn't in GNOME :-) If you could point out what Wine is doing in wrong way I'm all ears.
Don't get defensive, everyone is completely willing to change metacity. All I'm saying is that there's no point trying to appeal to specs in this case. There's no question that we need some heuristic "try to detect legacy apps" code which the spec in no way covers. KDE also has some heuristic code for this sort of thing, as does any reasonable window manager. As with any heuristic it's a little touch-and-go/trial-and-error. I believe several WMs including KDE and metacity have code something like: - if a window resizes itself to fullscreen, assume fullscreen state was intended This heuristic can have various tweaks, such as only assuming fullscreen if the window is undecorated. From other posts, I gather that WINE pretty much has this same heuristic internally, because the windows API doesn't have a fullscreen state, just "screen sized + on top" In addition to whether a window is currently fullscreen, metacity cares whether a window can be fullscreened (so it knows whether to offer the keybinding, etc.). So that's the algorithm in recalc_window_features() that may need some tuning, since apparently on Windows fullscreen apps still have decorations. (Or this is the hypothesis I threw out there.) Now, the 100% correct app behavior IMO would be to not change the size hints or the window size when the fullscreen hint is advertised as supported by the WM. This allows the WM to remember the pre-fullscreen size and support restoring to it, and allows the WM to allow users to leave the fullscreen state. WINE can't be fixed to be really right I gather, since the Windows API does not provide enough information. There's an "impedance" problem. So someone will need to tweak recalc_window_features a bit in metacity. It's not a big deal. An alternative fix might be to extend the WINE heuristic to ignore the app's setting the size on the window and instead convert it _solely_ into a fullscreen state request. Either way, we're talking heuristics and not specs.
If nothing else, in modern desktops it's quite hard to tell which configure requests are user-originated and which are not.
That one is simple: if a request is being originated by a user interaction it's a user's request and might be restricted; if it's a result of an API call it's done programmatically and should be executed by all means.
The WM has no reliable idea whether a request was originated by a user interaction, because not all user interactions are originated through the window manager. Years ago in "strict compliance" mode metacity used to deny all application configure requests entirely, and it broke a lot of stuff including things users felt they had asked for. There's also a social problem, which is that if you ship a WM that only honors user-originated requests, all the app authors will start setting the "user originated this" flag so you honor their requests anyway. It's kind of a lost cause for that reason. I did try it experimentally though when first coding metacity. Havoc
"Havoc Pennington" <hp(a)redhat.com> wrote:
Anyway, few WM bugs can be resolved by appeal to specifications alone...
Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and doesn't in GNOME :-) If you could point out what Wine is doing in wrong way I'm all ears.
Don't get defensive, everyone is completely willing to change metacity. All I'm saying is that there's no point trying to appeal to specs in this case.
That's completely understood.
There's no question that we need some heuristic "try to detect legacy apps" code which the spec in no way covers. KDE also has some heuristic code for this sort of thing, as does any reasonable window manager. As with any heuristic it's a little touch-and-go/trial-and-error.
I believe several WMs including KDE and metacity have code something like: - if a window resizes itself to fullscreen, assume fullscreen state was intended
This heuristic can have various tweaks, such as only assuming fullscreen if the window is undecorated.
From other posts, I gather that WINE pretty much has this same heuristic internally, because the windows API doesn't have a fullscreen state, just "screen sized + on top"
That's correct, except that window size may not match the screen size accurately, window size may be larger that screen, because applications sometimes instead of removing window decorations (caption and borders) simply resize a window so that client window area covers the screen. An algorithm in Wine which asks a WM to activate fullscreen state for a window is quite simple: it checks the size of a just resized visible window and if it's equal or larger than screen size sends an event to a WM. We are trying to understand at the moment why metacity sometimes ignores such a request: window size and visibility should not be a reason for it (except if metacity expects a window to have exactly same size as the screen has, not larger than that), probably window decorations or something else do. On the related note: any idea why adding _NET_WM_STATE_ABOVE to a window makes it cover the GNOME dock, but GNOME top panel still remains on the top? Thanks for your help. -- Dmitry.
Dmitry Timoshkov wrote:
An algorithm in Wine which asks a WM to activate fullscreen state for a window is quite simple: it checks the size of a just resized visible window and if it's equal or larger than screen size sends an event to a WM. We are trying to understand at the moment why metacity sometimes ignores such a request: window size and visibility should not be a reason for it (except if metacity expects a window to have exactly same size as the screen has, not larger than that), probably window decorations or something else do.
Currently what appears to be triggering the issue in metacity is that the window's minimum and maximum size are also changed, such that the window is not resizable. There's an exception to this rule if the window is already fullscreen-size, but the exception kicks in only for undecorated windows. I'd try just removing the !decorated line from metacity, or testing this theory by building a version of WINE that disables decorations in this case, just to see if it helps.
On the related note: any idea why adding _NET_WM_STATE_ABOVE to a window makes it cover the GNOME dock, but GNOME top panel still remains on the top?
afaik the top and bottom panels should always be in the same layer (so both above or both below). Elijah would know better though. ABOVE windows can be below the panels if they don't have focus iirc. Havoc
On 7/7/06, Havoc Pennington <hp(a)redhat.com> wrote:
Dmitry Timoshkov wrote:
An algorithm in Wine which asks a WM to activate fullscreen state for a window is quite simple: it checks the size of a just resized visible window and if it's equal or larger than screen size sends an event to a WM. We are trying to understand at the moment why metacity sometimes ignores such a request: window size and visibility should not be a reason for it (except if metacity expects a window to have exactly same size as the screen has, not larger than that), probably window decorations or something else do.
Currently what appears to be triggering the issue in metacity is that the window's minimum and maximum size are also changed, such that the window is not resizable. There's an exception to this rule if the window is already fullscreen-size, but the exception kicks in only for undecorated windows.
I'd try just removing the !decorated line from metacity, or testing this theory by building a version of WINE that disables decorations in this case, just to see if it helps.
I'm pretty sure that would fix this issue for WINE apps, since WINE is manually sending a please-put-this-app-in-fullscreen-mode message on behalf of the app. We should probably also fix the heuristics in src/stack.c:window_is_fullscreen_size() as well for other apps. (The difference between the two pieces of code is _allowing_ an app to be fullscreened in the first case, and automatically making an app be fullscreen without it properly requesting it in the second) I filed this pair of issues at http://bugzilla.gnome.org/show_bug.cgi?id=346927.
On the related note: any idea why adding _NET_WM_STATE_ABOVE to a window makes it cover the GNOME dock, but GNOME top panel still remains on the top?
afaik the top and bottom panels should always be in the same layer (so both above or both below). Elijah would know better though.
ABOVE windows can be below the panels if they don't have focus iirc.
As per the EWMH suggestions, stacking order is layered according to * windows of type _NET_WM_TYPE_DESKTOP * windows having state _NET_WM_STATE_BELOW * windows not belonging in any other layer * windows of type _NET_WM_TYPE_DOCK (unless they have state _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE * focused windows having state _NET_WM_STATE_FULLSCREEN Windows within a layer are reordered according to use (e.g. user clicks on the window and it gets raised above other windows within the same layer). Since windows with the above type are in the same layer as docks, it's not at all surprising that panels will be below type above windows sometimes and above them at other times. To have docks always below (or alternatively always above) windows of type above, the two types would have to be sorted into separate layers. Hope that helps, Elijah
"Elijah Newren" <newren(a)gmail.com> wrote:
On 7/7/06, Havoc Pennington <hp(a)redhat.com> wrote:
Currently what appears to be triggering the issue in metacity is that the window's minimum and maximum size are also changed, such that the window is not resizable. There's an exception to this rule if the window is already fullscreen-size, but the exception kicks in only for undecorated windows.
I'd try just removing the !decorated line from metacity, or testing this theory by building a version of WINE that disables decorations in this case, just to see if it helps.
I'm pretty sure that would fix this issue for WINE apps, since WINE is manually sending a please-put-this-app-in-fullscreen-mode message on behalf of the app. We should probably also fix the heuristics in src/stack.c:window_is_fullscreen_size() as well for other apps. (The difference between the two pieces of code is _allowing_ an app to be fullscreened in the first case, and automatically making an app be fullscreen without it properly requesting it in the second) I filed this pair of issues at http://bugzilla.gnome.org/show_bug.cgi?id=346927.
I'll try to provide some investigation based on the todays Wine snapshot running a demo of game Thief: Here the game creates its main window: trace:win:WIN_CreateWindowEx "Thief 1.33 " "LookingGlassTechnologies_WindowsGameShell_v2" ex=00000000 style=02ca0000 0,0 640x512 parent=(nil) menu=(nil) inst=0x400000 params=(nil) trace:win:dump_window_styles style: WS_CLIPCHILDREN WS_CAPTION WS_SYSMENU WS_MINIMIZEBOX trace:win:dump_window_styles exstyle: trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (0,0)-(640,512) style 06ca0000 trace:x11drv:create_icon_window created 2000002 trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,512) trace:win:WINPOS_GetMinMaxInfo 1282 1026 / -1 -1 / 1288 1032 / 108 27 trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (0,0)-(640,512) style 06ca0000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 3,22,634x487 after 6609462c changes=f trace:x11drv:X11DRV_CreateWindow hwnd 0x10024 cs 0,0 640x512 trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (3,22)-(637,509) style 06ca0000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 3,22,634x487 after 6609462c changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10024 window 0,0,640,512 client 3,22,637,509 whole 3,22,637,509 X client 0,0,634,487 xwin 2000001 trace:win:WIN_CreateWindowEx created window 0x10024 trace:win:SetForegroundWindow 0x10024 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 3,22,634x487 (event 3,22,634x487) trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,512) trace:event:process_events processed 1 events trace:win:SetFocus 0x10024 prev (nil) trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=0, wasVisible 0 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=0, wasVisible 0 trace:win:alloc_winproc reusing 0xffff000c for 0x2034b314/(nil) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7ff401a8)->((nil),00000008) fixme:d3d:IWineD3DStateBlockImpl_Release Releasing primary stateblock trace:win:alloc_winproc reusing 0xffff000c for 0x2034b314/(nil) trace:win:WIN_SetWindowLong 0x10024 -20 8 A trace:win:WIN_SetWindowLong 0x10024 -20 8 A Now the game changes style of its man window to WS_POPUP (top level window without any decorations) trace:win:WIN_SetWindowLong 0x10024 -16 80000000 A ... and calls ShowWindow(SW_SHOW) on it: trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=5, wasVisible 0 trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,0 (0x0), flags 00000043 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_SHOWWINDOW trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,0 0x0 flags 00000043 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,0 0x0 flags 00001843 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,512) style 80000000 new (0,0)-(640,512) trace:x11drv:SWP_DoOwnedPopups (0x10024) hInsertAfter = (nil) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (3,22)-(637,509) style 90000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 0,0,640x512 after 6609462c changes=4f window 0x10024 becomes visible and mapped to the screen: trace:x11drv:X11DRV_set_window_pos mapping win 0x10024 trace:win:SetForegroundWindow 0x10024 trace:x11drv:X11DRV_SetWindowPos status flags = 1847 [some unrelated stuff skipped] Now the game calls ShowWindow(SW_HIDE) on its main window to hide it: trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=0, wasVisible 1 trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,0 (0x0), flags 00000083 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_HIDEWINDOW trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,0 0x0 flags 00000083 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,0 0x0 flags 00001883 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,512) style 90000000 new (0,0)-(640,512) trace:x11drv:SWP_DoOwnedPopups (0x10024) hInsertAfter = (nil) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,512) client (0,0)-(640,512) style 80000000 trace:x11drv:X11DRV_set_window_pos unmapping win 0x10024 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 0,0,640x512 after 201b9608 changes=40 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:x11drv:X11DRV_SetWindowPos status flags = 1887 trace:win:WINPOS_ActivateOtherWindow win = (nil) fg = 0x10024 trace:win:SetForegroundWindow (nil) trace:win:SetActiveWindow (nil) trace:win:WIN_SetWindowLong 0x10024 -16 6ca0000 A trace:win:WIN_SetWindowLong 0x10024 -20 8 A trace:win:WIN_SetWindowLong 0x10024 -16 80000000 A trace:win:SetForegroundWindow 0x10024 At this point WM decides to correct position of an invisible application's window (why?) to shift it below the top GNOME top panel by 25 pixels (btw, that's why I wrongly thought that the top GNOME top panel remained above in Z order of the main game's window, actually they do not overlap each other). For some reason WM does this in a very inefficient way in multiple steps: trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,0,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,512) trace:x11drv:X11DRV_ConfigureNotify 0x10024 moving from (0,0) to (0,25) trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,25 (640x512), flags 00000015 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,25 640x512 flags 00000015 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,25 640x512 flags 00001815 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,512) style 80000000 new (0,25)-(640,537) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,25)-(640,537) client (0,25)-(640,537) style 80000000 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:x11drv:X11DRV_SetWindowPos status flags = 0805 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events MapNotify for hwnd/window 0x10024/2000001 Last line above confuses a lot: why WM behind our back maps a window? What may be a reason behind that? That leads to a lot of confusion later: Wine thinks that a window is not visible and ignores take focus client message below, while WM starts to send focus messages to the window: trace:event:process_events Expose for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_Expose win 0x10024 (2000001) 0,0 640x512 trace:win:RedrawWindow 0x10024 rect (0,0)-(640,512) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN trace:event:process_events FocusIn for hwnd/window 0x10024/2000001 trace:event:EVENT_FocusIn win 0x10024 xwin 2000001 detail=NotifyNonlinear trace:event:process_events KeymapNotify for hwnd/window (nil)/0 trace:event:process_events ClientMessage for hwnd/window 0x10024/2000001 trace:event:handle_wm_protocols got take focus msg for 0x10024, enabled=1, visible=0 (style 80000000), focus=(nil), active=0x10024, fg=0x10024, last=(nil) Note visible=0 above and style 80000000 (just WS_POPUP, there is no WS_VISIBLE). trace:event:process_events processed 10 events trace:win:SetFocus 0x10024 prev (nil) fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7ff401a8)->(0x10024,00000051) The game resizes its window to prepare it for future resolution change: trace:win:MoveWindow 0x10024 320,272 640x480 1 trace:win:SetWindowPos hwnd 0x10024, after (nil), 320,272 (640x480), flags 00000014 trace:win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 320,272 640x480 flags 00000014 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 320,272 640x480 flags 00001814 trace:x11drv:SWP_DoWinPosChanging current (0,25)-(640,537) style 80000000 new (320,272)-(960,752) trace:x11drv:SWP_DoNCCalcSize hwnd 0x10024 old win (0,25)-(640,537) old client (0,25)-(640,537) new win (320,272)-(960,752) new client (320,272)-(960,752) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (320,272)-(960,752) client (320,272)-(960,752) style 80000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 320,272,640x480 after 6609462c changes=b trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:x11drv:X11DRV_SetWindowPos status flags = 0004 Now the game calls ShowWindow(SW_SHOW) on its main window to make it visible: trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=5, wasVisible 0 trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,0 (0x0), flags 00000043 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_SHOWWINDOW trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,0 0x0 flags 00000043 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,0 0x0 flags 00001843 trace:x11drv:SWP_DoWinPosChanging current (320,272)-(960,752) style 80000000 new (320,272)-(960,752) trace:x11drv:SWP_DoOwnedPopups (0x10024) hInsertAfter = (nil) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (320,272)-(960,752) client (320,272)-(960,752) style 90000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 320,272,640x480 after 6609462c changes=40 trace:x11drv:X11DRV_set_window_pos mapping win 0x10024 At this point window 0x10024 has style 0x90000000 (WS_POPUP | WS_VISIBLE), i.e. it's a top level window without any decorations (caption or border), it's visible, left/top corner is at 320,272, and its dimensions are 640x480. Note to Wine developers: the window is managed depite the fact that it has only WS_POPUP set at this point because originally it was created as overlapped with WS_CAPTION style set. trace:win:SetForegroundWindow 0x10024 trace:x11drv:X11DRV_SetWindowPos status flags = 1847 trace:win:SetForegroundWindow 0x10024 fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7ff401a8)->(0x10024,00000008) The game moves its main window to 0,0 in preparation to resolution change: trace:win:SetWindowPos hwnd 0x10024, after 0xffffffff, 0,0 (640x480), flags 00000140 trace:win:dump_winpos_flags flags: SWP_SHOWWINDOW SWP_NOCOPYBITS trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after 0xffffffff, swp 0,0 640x480 flags 00000140 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after 0xffffffff, swp 0,0 640x480 flags 00001940 trace:x11drv:SWP_DoWinPosChanging current (320,272)-(960,752) style 90000000 new (0,0)-(640,480) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,480) client (0,0)-(640,480) style 90000000 trace:x11drv:X11DRV_sync_window_position setting win 2000001 pos 0,0,640x480 after 6609462c changes=43 trace:x11drv:X11DRV_set_window_pos mapping non zero size or off-screen win 0x10024 trace:win:SetForegroundWindow 0x10024 trace:x11drv:X11DRV_SetWindowPos status flags = 0805 fixme:ddraw:IDirectDrawImpl_SetCooperativeLevel (0x7ff401a8)->(0x10024,00000051) ... and changes screen resolution to 640x480: fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 32 to 16 trace:xrandr:X11DRV_XRandR_SetCurrentMode Changing Resolution to 640x480 @75 Hz trace:xrandr:X11DRV_XRandR_SetCurrentMode Resizing X display to 640x480 @75 Hz trace:x11drv:X11DRV_handle_desktop_resize desktop 0x10020 change to (640x480) trace:win:GetWindowRect hwnd 0x10020 (0,0)-(1280,1024) trace:win:BeginPaint hdc = 0x1e8 box = (0,0 - 0,0), fErase = 0 Wine detects that the window 0x10024 became full screen and asks WM to change its state: trace:x11drv:update_fullscreen_state setting fullscreen state for hwnd 0x10024 to true For some reason the game moves the window again, but that should have no effect since actual window position is not being changed: trace:win:MoveWindow 0x10024 0,0 640x480 1 trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,0 (640x480), flags 00000014 trace:win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,0 640x480 flags 00000014 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,0 640x480 flags 00001814 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,480) style 90000000 new (0,0)-(640,480) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,0)-(640,480) client (0,0)-(640,480) style 90000000 trace:x11drv:X11DRV_set_window_pos mapping non zero size or off-screen win 0x10024 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,480) trace:win:RedrawWindow 0x10024 rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN trace:x11drv:X11DRV_SetWindowPos status flags = 1807 trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,480) Now WM insists again to move the window below its top panel by 25 pixels (again, why?) effectively making it not a fullscrreen one. Again, for some reason WM does this in a very inefficient way in multiple steps: trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x480 (event 320,272,640x480) trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,480) trace:x11drv:X11DRV_ConfigureNotify 0x10024 moving from (0,0) to (0,25) trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,25 (640x480), flags 00000015 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,25 640x480 flags 00000015 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,25 640x480 flags 00001815 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,480) style 90000000 new (0,25)-(640,505) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,25)-(640,505) client (0,25)-(640,505) style 90000000 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:win:RedrawWindow 0x10024 rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN trace:x11drv:X11DRV_SetWindowPos status flags = 0805 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 320,272,640x480 (event 320,272,640x480) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,505) trace:x11drv:X11DRV_ConfigureNotify 0x10024 moving from (0,25) to (320,272) trace:win:SetWindowPos hwnd 0x10024, after (nil), 320,272 (640x480), flags 00000015 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 320,272 640x480 flags 00000015 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 320,272 640x480 flags 00001815 trace:x11drv:SWP_DoWinPosChanging current (0,25)-(640,505) style 90000000 new (320,272)-(960,752) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (320,272)-(960,752) client (320,272)-(960,752) style 90000000 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:win:RedrawWindow 0x10024 rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN trace:x11drv:X11DRV_SetWindowPos status flags = 0805 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x480 (event 0,25,640x480) trace:win:GetWindowRect hwnd 0x10024 (320,272)-(960,752) trace:x11drv:X11DRV_ConfigureNotify 0x10024 moving from (320,272) to (0,25) trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,25 (640x480), flags 00000015 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,25 640x480 flags 00000015 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,25 640x480 flags 00001815 trace:x11drv:SWP_DoWinPosChanging current (320,272)-(960,752) style 90000000 new (0,25)-(640,505) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,25)-(640,505) client (0,25)-(640,505) style 90000000 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:win:RedrawWindow 0x10024 rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN trace:x11drv:X11DRV_SetWindowPos status flags = 0805 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x480 (event 0,25,640x480) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,505) [end of the interesting parts of the log] The log above makes me ask several questions: 1. Why the WM thinks that it knows better than the app where to place its window and insists on moving it to another position? That's not a user related interaction related to moving a window using mouse or a keyboard, IMO the WM should not do this kind of things behind applications back. 2. How that could happen that the WM maps a window to the screen although it clearly was not asked to? I hope that the log above will help to shed some light into the investigated problem and will allow to find a resolution to it. If you need I can provide a similar log for KDE to compare how it behaves in the same situation. Many thanks for you help. -- Dmitry.
Dmitry Timoshkov wrote:
1. Why the WM thinks that it knows better than the app where to place its window and insists on moving it to another position? That's not a user related interaction related to moving a window using mouse or a keyboard, IMO the WM should not do this kind of things behind applications back.
2. How that could happen that the WM maps a window to the screen although it clearly was not asked to?
I hope that the log above will help to shed some light into the investigated problem and will allow to find a resolution to it.
I can't tell enough from this log, because remember things are asynchronous. So we don't know what information metacity already had or did not have at each point in the log. i.e. WINE may think it said "hide the window" then get a configure notify, but metacity may have sent the configure notify BEFORE the window was hidden. (Just an example.) I'd suggest getting a new WINE log but with metacity verbose logging on also. Then we'll have the exact same run of this app from both sides of the issue and we can tell exactly what happened during that run of the app. Metacity verbose log will mention all the property changes and configure requests and so forth. btw the "synchronous" vs. "asynchronous" API impedance mismatch is a big problem; I worked with the Eclipse project on this years ago, where they had it with SWT vs. GTK. Though they did not afaik use the advice we gave them, which was to leave X/gtk working asynchronously but have a "write-through cache" of the server side state so things looked synchronous from the SWT point of view. Of course the most robust approach is to design any API that has to run on top of X to have async semantics, but that's not an option with exisitng APIs like SWT or win32. Havoc
"Havoc Pennington" <hp(a)redhat.com> wrote:
I can't tell enough from this log, because remember things are asynchronous. So we don't know what information metacity already had or did not have at each point in the log. i.e. WINE may think it said "hide the window" then get a configure notify, but metacity may have sent the configure notify BEFORE the window was hidden. (Just an example.)
I'd suggest getting a new WINE log but with metacity verbose logging on also. Then we'll have the exact same run of this app from both sides of the issue and we can tell exactly what happened during that run of the app. Metacity verbose log will mention all the property changes and configure requests and so forth.
btw the "synchronous" vs. "asynchronous" API impedance mismatch is a big problem; I worked with the Eclipse project on this years ago, where they had it with SWT vs. GTK. Though they did not afaik use the advice we gave them, which was to leave X/gtk working asynchronously but have a "write-through cache" of the server side state so things looked synchronous from the SWT point of view.
I'm attaching 2 logs: 1st one is a Wine log (thief.log.bz2) produced by running WINEDEBUG=+win,+xrandr,+event,+x11drv,+synchronous ~/wine/wine THIEFD.EXE i.e. this log avoids an issue with asynchronous X behaviour, Wine calls 'XSynchronize( display, True );' on startup once it sees '+synchronous' in the debug switches. The 2nd is a metacity log (metacity_verbose.log.bz2) produced by starting X session with METACITY_VERBOSE=1, running Wine with the above debug switches. I've stripped the log by removing everything before 1st appearance of the window id 0x2200001 in the log and aftre destruction of that window. Please let me know if you need anything else. Thanks. -- Dmitry.
Dmitry Timoshkov wrote:
At this point WM decides to correct position of an invisible application's window (why?)
In the metacity log, this is in the proper order (the window is mapped, metacity sets its position, and the window is withdrawn). I would conclude that this is a race; remember that if the app calls map, unmap then some events that occurred prior to the unmap request can still arrive after the unmap request. This is the asynchronicity I was talking about. to shift it below the top GNOME top panel by 25 pixels (btw,
that's why I wrongly thought that the top GNOME top panel remained above in Z order of the main game's window, actually they do not overlap each other).
Metacity does this with all windows (keeps them below the panel) unless there's some reason not to (such as fullscreen); it's a longstanding UI decision.
For some reason WM does this in a very inefficient way in multiple steps:
trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,0,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,0)-(640,512) trace:x11drv:X11DRV_ConfigureNotify 0x10024 moving from (0,0) to (0,25) trace:win:SetWindowPos hwnd 0x10024, after (nil), 0,25 (640x512), flags 00000015 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE trace:x11drv:X11DRV_SetWindowPos hwnd 0x10024, after (nil), swp 0,25 640x512 flags 00000015 trace:x11drv:SWP_DoWinPosChanging hwnd 0x10024, after (nil), swp 0,25 640x512 flags 00001815 trace:x11drv:SWP_DoWinPosChanging current (0,0)-(640,512) style 80000000 new (0,25)-(640,537) trace:x11drv:X11DRV_set_window_pos win 0x10024 window (0,25)-(640,537) client (0,25)-(640,537) style 80000000 trace:win:RedrawWindow 0x10024 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME trace:x11drv:X11DRV_SetWindowPos status flags = 0805 trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events ConfigureNotify for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_ConfigureNotify win 0x10024 new X rect 0,25,640x512 (event 0,25,640x512) trace:win:GetWindowRect hwnd 0x10024 (0,25)-(640,537) trace:event:process_events MapNotify for hwnd/window 0x10024/2000001
Last line above confuses a lot: why WM behind our back maps a window? What may be a reason behind that?
From the metacity log, it looks to me like WINE here withdraws the window, turns on window decorations, then remaps the window. Metacity then has to unmap/map one more time in order to place the window inside its window frame. Undecorated windows don't have a frame so don't have the extra unmap/map caused by reparenting, but normal windows do. Clients and WMs both have to distinguish between maps that are incidental to implementation details and maps that have a meaning in the ICCCM. Essentially you need a "withdrawn" flag on windows indicating whether you have yourself mapped or unmapped the window. The WM may also map/unmap in order to reparent, manage workspaces, etc. and you should just ignore those map events most of the time. If you need a "steady state" mapped status that matches the Windows API, then you would need to "simulate" it on the client side, by e.g. using the client-side withdrawn flag instead of the mapped state.
That leads to a lot of confusion later: Wine thinks that a window is not visible and ignores take focus client message below, while WM starts to send focus messages to the window:
trace:event:process_events Expose for hwnd/window 0x10024/2000001 trace:x11drv:X11DRV_Expose win 0x10024 (2000001) 0,0 640x512 trace:win:RedrawWindow 0x10024 rect (0,0)-(640,512) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN trace:event:process_events FocusIn for hwnd/window 0x10024/2000001 trace:event:EVENT_FocusIn win 0x10024 xwin 2000001 detail=NotifyNonlinear
X will not send focus events to unmapped windows btw, if it's useful to rely on that behavior.
The log above makes me ask several questions:
1. Why the WM thinks that it knows better than the app where to place its window and insists on moving it to another position? That's not a user related interaction related to moving a window using mouse or a keyboard, IMO the WM should not do this kind of things behind applications back.
As I mentioned before, there is no way to tell in the WM what is user-initiated and what isn't, so any policies on window positioning have to be for all configure requests (though the WM can and does adjust the policy for window type, etc.). metacity keeps windows from overlapping the panel because most of the time that results in a better UI; this isn't anything new, it's been in GNOME for years. Plenty of just normal document editor or dialog type windows try to open at 0,0 (which in GNOME would cover up the applications launcher menu) so metacity keeps them underneath that. It'd be pretty annoying to use GNOME otherwise. A philosophical problem here is that you're trying to be a managed window and trying to do everything yourself at the same time. This can be done, but tends to be the hard path; the easy paths are to just be override redirect (though I consider that broken, it may be required to make wine work) or to just let the WM do everything (e.g. set the fullscreen state and don't do your own resizing, undecorating, and so forth that might confuse matters). Some ideas: - if setting the vid mode viewport presumably you will also end up needing to grab the pointer... in this case there's little downside to using override redirect since no "window management" is possible anyhow - figure out how to get the fullscreen state set... unfortunately metacity doesn't understand vid modes, which will make this not really work right - patch metacity to understand vid modes (are there "vid mode events"?) - could you put the vid mode viewport in a different place, e.g. in the middle of the screen, then offset all Windows positions requests to the viewport? (too much of a hack? would it work?)
2. How that could happen that the WM maps a window to the screen although it clearly was not asked to?
If your window is withdrawn, it would be a bad bug for the WM to map it; but in the metacity log I see no evidence of this happening. However, if your window is currently in the normal/managed state, the WM _must_ unmap/map from time to time in order to work; WMs work in different ways but e.g. creating the frame by ReparentWindow to the frame window is pretty standard and causes unmap/map events. Metacity also implements multiple workspaces and minimization by unmapping, it's a bit unusual to do workspaces this way, but many or even most WMs do minimization this way. Havoc
Something I think I may have suggested long ago is some sort of "WINE hints" that WMs could implement; in essence, have calls to the WM that map to Windows API calls exactly and try to have the same semantics. IOW implement the windows API in conjunction with the WM. This is probably the only way to make things 100%, 100% always work right; because it gets past the "impedance mismatch" between how native X apps work and how windows API apps work by giving them different codepaths. I wouldn't know how to do this, but it's an idea. Havoc
"Havoc Pennington" <hp(a)redhat.com> wrote:
to shift it below the top GNOME top panel by 25 pixels (btw,
that's why I wrongly thought that the top GNOME top panel remained above in Z order of the main game's window, actually they do not overlap each other).
Metacity does this with all windows (keeps them below the panel) unless there's some reason not to (such as fullscreen); it's a longstanding UI decision.
It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else?
Last line above confuses a lot: why WM behind our back maps a window? What may be a reason behind that?
From the metacity log, it looks to me like WINE here withdraws the window, turns on window decorations, then remaps the window.
Metacity then has to unmap/map one more time in order to place the window inside its window frame. Undecorated windows don't have a frame so don't have the extra unmap/map caused by reparenting, but normal windows do.
Thanks for the explanation, now the behavour I see in the log looks reasonable to me: a window gets mapped/unmapped in a succession, and actually Wine handles that correctly since it has an internal visibility state for each window. This answers the question (2) as well. -- Dmitry.
Dmitry Timoshkov wrote:
It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else?
I'm not next to the machine where I had the log unpacked, so I'm not sure, but yeah if fullscreenable=0 when the client message is received then that would cause it to be ignored. I think some tweaking to when fullscreenable is set would be well worth trying out as a solution. Havoc
"Havoc Pennington" <hp(a)redhat.com> wrote:
Dmitry Timoshkov wrote:
It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else?
I'm not next to the machine where I had the log unpacked, so I'm not sure, but yeah if fullscreenable=0 when the client message is received then that would cause it to be ignored. I think some tweaking to when fullscreenable is set would be well worth trying out as a solution.
Anything else I can do to help fixing this problem? Do you need any further testing/logs/investigation on the Wine side? Thanks. -- Dmitry.
Dmitry Timoshkov wrote:
"Havoc Pennington" <hp(a)redhat.com> wrote:
Dmitry Timoshkov wrote:
It's OK that a WM constrains windows to be placed inside of its work area but still allows to place them into a fullscreen state on request. How would you suggest to properly inform a WM that a window needs to be in a fullscreen state? Does metacity ignore ClientMessage/_NET_WM_STATE_FULLSCREEN request due to 'fullscreenable = 0' or something else?
I'm not next to the machine where I had the log unpacked, so I'm not sure, but yeah if fullscreenable=0 when the client message is received then that would cause it to be ignored. I think some tweaking to when fullscreenable is set would be well worth trying out as a solution.
Anything else I can do to help fixing this problem? Do you need any further testing/logs/investigation on the Wine side?
You could try patching metacity with either of the fixes mentioned here (or some other fix) and verify that they work for wine: http://bugzilla.gnome.org/show_bug.cgi?id=346927 They are both basically 1-2 line changes, so there's no patch there but there should be enough info to easily patch metacity. The other thing to test I guess is whether apps like e.g. mplayer/xine still get heuristically fullscreened, though for all I know recent mplayer uses the proper hints now. It's best to add further info on the bug so it doesn't get lost. Havoc
"Havoc Pennington" <hp(a)redhat.com> wrote:
You could try patching metacity with either of the fixes mentioned here (or some other fix) and verify that they work for wine: http://bugzilla.gnome.org/show_bug.cgi?id=346927
They are both basically 1-2 line changes, so there's no patch there but there should be enough info to easily patch metacity.
I've added a patch there which fixes the problem for me. Here is a comment I've put there to explain why the patch is needed: "The problem appears to not be related to the heuristics Metacity uses to check whether a window may be fullscreened, but rather to a missing update of a window state after screen resolution change so that heuristics can do their work. I've used slightly old Metacity 2.10.0 sources, but hopefully the attached patch is still relevant." Please let me know whether the patch is a right way to fix the bug, or you need further explanations. Thanks. -- Dmitry.
"Dmitry Timoshkov" <dmitry(a)codeweavers.com> wrote:
"Havoc Pennington" <hp(a)redhat.com> wrote:
You could try patching metacity with either of the fixes mentioned here (or some other fix) and verify that they work for wine: http://bugzilla.gnome.org/show_bug.cgi?id=346927
They are both basically 1-2 line changes, so there's no patch there but there should be enough info to easily patch metacity.
I've added a patch there which fixes the problem for me.
I've attached a couple of patches based on Havoc's suggestions to the bug above. The patches fix Thief game and IE's fullscreen mode for me. Vincent, could you try them and report if any of the patches fixes Firefox for you? -- Dmitry.
The patches in comments #13 and #5 had no effect. #6 didn't apply cleanly (I'm using metacity 2.14.3--I tried to get the latest version from cvs, but it requires a newer gtk than I have). After applying it, firefox is fixed, except that when returning from fullscreen mode the window is bigger than it had been (unless it was maximized). I didn't try #2 because firefox doesn't change the screen resolution. On 8/4/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
I've attached a couple of patches based on Havoc's suggestions to the bug above. The patches fix Thief game and IE's fullscreen mode for me. Vincent, could you try them and report if any of the patches fixes Firefox for you?
-- Dmitry.
-- Vincent Povirk
On 8/6/06, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote:
The patches in comments #13 and #5 had no effect.
I didn't try #2 because firefox doesn't change the screen resolution.
#2, #5, and #13 were all alternative versions of patches for the same issue for the "Thief" game. It's not surprising that these don't affect firefox, as all were just meant to help in the case of screen resolution changing.
#6 didn't apply cleanly (I'm using metacity 2.14.3--I tried to get the latest version from cvs, but it requires a newer gtk than I have). After applying it, firefox is fixed, except that when returning from fullscreen mode the window is bigger than it had been (unless it was maximized).
Actually, that's because Dmitry was using an older version. The patch actually appiled to head would have also applied to 2.14.3. :) Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them. Hope that helps, Elijah
"Elijah Newren" <newren(a)gmail.com> wrote:
Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them.
Wine asks a WM to switch off the fullscreen state as a result of app's request to change its window size to something less than a screen resolution. So, the fix would be to change Metacity to not restore window's size if it's no more the same as it was before entering the full screen state. Also I notice that IE when returning from fullscreen state doesn't restore its caption back, while under KDE it does. Let me know whether it's a known/fixed bug, or if further investigation is needed. -- Dmitry.
On 8/7/06, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote:
"Elijah Newren" <newren(a)gmail.com> wrote:
Anyway, the returning from fullscreen mode bug makes perfect sense, and I'm pretty sure I know the cause: metacity tries to return the window to the size it was before it was fullscreened, and it sounds like it was successful in this case. Remember that the application resized itself to the size of the screen, then you (wine) noticed that and decided to send the fullscreen toggle message. Thus, the size the window had before being fullscreen, happened to be a size equal to the size of the screen. Since wine has added heuristics for detecting when an app sets its size to the size of the screen, I think it either needs to add heuristics for resizing back to normal size, or to just have the fullscreen toggle message replace the apps' resizing commands instead of supplementing them.
Wine asks a WM to switch off the fullscreen state as a result of app's request to change its window size to something less than a screen resolution. So, the fix would be to change Metacity to not restore window's size if it's no more the same as it was before entering the full screen state.
Ugh. Apparently, I busted our fullscreen handling in metacity>=2.14.x in lots of cases in addition to problems we've being talking about in this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6 if you're curious. Anyway, I think I've fixed all those issues, and I believe my fixes should cover this last issue of yours (making windows return to the original size correctly). Is there any chance I could get you test (with metacity 2.15.34) and verify? (You could also backport the patch from bug 343115...) Thanks for all the help! Elijah
"Elijah Newren" <newren(a)gmail.com> wrote:
Ugh. Apparently, I busted our fullscreen handling in metacity>=2.14.x in lots of cases in addition to problems we've being talking about in this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6 if you're curious. Anyway, I think I've fixed all those issues, and I believe my fixes should cover this last issue of yours (making windows return to the original size correctly). Is there any chance I could get you test (with metacity 2.15.34) and verify? (You could also backport the patch from bug 343115...)
Since I'm on FC4 I can't test latest Metacity releases because it requires newer GTK, and backporting is not really possible since version 2.10 provided with FC4 is too different from 2.15.x series. -- Dmitry.
"Elijah Newren" <newren(a)gmail.com> wrote:
Ugh. Apparently, I busted our fullscreen handling in metacity>=2.14.x in lots of cases in addition to problems we've being talking about in this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6 if you're curious. Anyway, I think I've fixed all those issues, and I believe my fixes should cover this last issue of yours (making windows return to the original size correctly). Is there any chance I could get you test (with metacity 2.15.34) and verify? (You could also backport the patch from bug 343115...)
Since I'm on FC4 I can't test latest Metacity releases because it requires newer GTK, and backporting is not really possible since version 2.10 provided with FC4 is too different from 2.15.x series.
-- Dmitry.
You could for instance install Gargnome. It allows you to install a new gnome version without messing up your system. By default this new gnome is installed in your home directory. Roderick -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
participants (6)
-
Dmitry Timoshkov -
Elijah Newren -
Havoc Pennington -
Mike Hearn -
Roderick Colenbrander -
Vincent Povirk