New Fullscreen Window Method

[Karl <karl glatzer gmx de>]

Hello,

This is meant to be the thread for wm-spec specific parts of a
discussion originated on the libsdl.org mailing list in this thread:

http://lists.libsdl.org/pipermail/sdl-libsdl.org/2012-January/thread.html#83512

In this mail I also want to elaborate my proposal for a new method to
create Fullscreen Windows.

Please consider this as a very very early draft and feel free to ask
questions!

The New Fullscreen Window Method

This method is not meant to be a replacement for setting the
_NET_WM_STATE_FULLSCREEN Atom, but as an alternative for applications
for which the current method defined in the wm-specs isn't sufficient.

I guess you will now ask youselves "In what way could
_NET_WM_STATE_FULLSCREEN be insufficient?" that's why I will elaborate
the current situation and it's shortcomings.

At the moment there are two choices for making a Window Fullscreen with
Fullscreen meaning that the window is on the top of the window stack,
normally positioned at x:0 y:0 in screen coordinates (I won't go into
details here) and the size of the current screen/view area.

The first, old and deprecated method to accomplish this sets
xoverride-redirect when creating the Window. This can be considered a
hack or misuse of the X11 Window System since this flag was never
considered to be used in this context.

Still nearly every Application which needs to be able to resize the
screen/view area uses this method either because at the time the code
was written the second method didn't exist or implementing the
second method didn't work or was just too complex.

The problem with this approach is that the Window Manager loses all
control over the window mostly resulting in unwanted behaviour and
conflicts with the Window Manager if the user can still access Window
Manager functions (via shortcuts etc.). As example: The window is still
drawn on top of other windows although it is unfocused after tabbing out.

The second method is setting the _NET_WM_STATE_FULLSCREEN Atom as
specified in the current wm-spec. No doubt this method works well
for most applications, but not always when resizing the screen/view area.

The biggest problem here is that the window needs to be maximized first
to become Fullscreen. This can't be done in some situations, because it
would break other things and also makes it impossible to use this on
windows which can't be resized.

If you like you can get a further clarification here:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2012-January/083683.html

Whew, now to the contents of the proposal itself. This is only a
description of how things should work and not a formal specification
although I already used some keywords that I think are essential and
probably won't change.

The idea of this is to establish a dialogue between the Window Manager
and the Application as opposed to the _NET_WM_STATE_FULLSCREEN method
which is used more in the sense of direct user control.

Setting _NET_WM_STATE_FULLSCREEN on the application window can be done
in two ways: either the application itself sets it or the user does via
a window manager feature. This tells the window manager to maximize the
window, stack it above panels and resize it to the size of the screen.

The way the proposal handles this is that when the user wants
_NET_WM_STATE_FULLSCREEN to be set (or unset) the window manager MUST
also send a Fullscreen Request Message (a special kind of client
message) to the Window.

If the application wants to handle the new Fullscreen method it MUST act
upon receiving this type of message. If it doesn't react the old
_NET_WM_STATE_FULLSCREEN behaviour is expected.

Now if the application receives the Fullscreen Request Message or if the
application wants to change the state of its window on its own it has to
send a Fullscreen Request Message containing ID of the Window that
should be set into Fullscreen Mode (or to Windowed Mode when it is
already Fullscreen).

When the Window Manager receives this Message it will remove the
_NET_WM_STATE_FULLSCREEN Atom and either adds it to a list of special
Fullscreen Windows or set another Atom indicating that this Window
partially handles Fullscreen itself (this is just an implementation
detail that needs to be agreed on). When in this list (or having the
Atom set) the Window Manager will NOT try to resize the Window but if it
is focused will set it on top of the window stack (for clarification:
Above of really everything including panels etc.) and disable the
checking of placement borders which were specified by panels etc. for
this Window.

If the window is already in the group (has the atom set) it is
considered Fullscreen and on receiving the message the window manager
will revert the changes (including removing the atom).

If all of this is done the application will receive another Fullscreen
Request Message which contains the information that the Window Manager
is done with its part on making the Window Fullscreen (or Windowed
again) and the application has now the chance to act upon this
accordingly by resizing the screen and setting the Window to the correct
position. This will now work as intended for Fullscreen Windows because
the panel limitations are disabled.