Re: wine's fullscreen code has no effect on metacity
On 8/7/06, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Elijah Newren [EMAIL PROTECTED] 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
Re: wine's fullscreen code has no effect on metacity
On 8/6/06, Vincent Povirk [EMAIL PROTECTED] 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
Re: wine's fullscreen code has no effect on metacity
On 7/6/06, Dmitry Timoshkov [EMAIL PROTECTED] 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
Re: wine's fullscreen code has no effect on metacity
On 7/4/06, Vincent Povirk [EMAIL PROTECTED] 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.
Re: wine's fullscreen code has no effect on metacity
On 7/6/06, Havoc Pennington [EMAIL PROTECTED] 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 [EMAIL PROTECTED] * 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)
Re: wine's fullscreen code has no effect on metacity
On 7/2/06, Vincent Povirk [EMAIL PROTECTED] 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
