Please no more Fullscreen cheats
Bill Spitzak
spitzak at gmail.com
Fri Jan 28 12:18:30 PST 2011
Carl-Philip Haensch wrote:
> Hi,
>
> I saw when you press F11 in a wayland window, the window will turn to
> "fullscreen" which means it will do the same crap as it does in X:
> Setting the window to overlap all windows, set the position to 0,0 and
> the size to w,h.
That makes a lot of sense to me. I really see no need to add extra api.
I suspect the problem is that you want the video mode to change. But it
seems like Wayland will allow this: besides the surface itself, a
transformation to screen space is also included (since this
transformation is almost free when combined with other effects the
compositor can do). The Wayland compositor can detect if all visible
windows are using the same scaling and it is a scale that can be done by
changing video mode, and change the video mode. When you alt+tab and
another window appears, it may switch the video mode back so it can draw
the window, but the game will now be scaled and look approximately the same.
> As you see in X, this concept is not really a concept, it's a hack that
> makes linux unusable for gaming or other fullscreen applications because
> you cannot switch a program without closing the fullscreen window first.
I tried this and alt+tab works just fine on a Gnome window manager.
I certainly like the "hack" in that it does not require additional API
to implement.
Eliminating all the enormous complexity talking to the window manager
(ie all the ICCCM and _NET_WM hints) is something I think Wayland can
accomplish. Hard coding behaviors into the api is not the way to advance
the design.
> + <!-- fullscreen toggles a flag if the compositor should stretch that
> + surface over the full screen without showing any other windows
> + or noritifations.
What about other windows the fullscreen app wants to put up, like
floating control panels?
The old x and y of the display is stored on
> + waylands site
Certainly the application can remember this! Also means that "reset" can
be the same api as the normal resize api. (also having written some
software to use Windows and Qt's "fullscreen" api, I have found it
impossible to make the software intelligent unless I kept track of and
control the original size anyway. For instance "save the current window
layout" was expected by users to remember the non-full-screen size if it
was run when full screen size was on. The result is that when the user
loads a saved full-screen layout we have to blink the windows in order
to force the system to get the smaller size closed, and we have to track
the small size anyway to save the full-screen layout).
> + Fullscreen windows should only be shown when they are on
> focus.-->
You mean it is impossible to push them to the back without them
resizing? That sounds pretty awful. I suppose this is some limitation of
how Windows does full-screen but I see no reason to reproduce these
limitations in Wayland.
More information about the wayland-devel
mailing list