On 7/7/06, Havoc Pennington hp@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