Re: New Fullscreen Window Method

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Thu, 02 Feb 2012 23:40:11 +0100 Karl <karl glatzer gmx de> said:

> 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.

imho, i disagree. the application really has no business going and playing with
randr and changing screen res (unless it is in-fact a screen-res conifg tool).
why? crashes and abnormal exits. so many games that like to do this also like
to crash, leaving there display configured at the resolution the game set - this
is pretty poor to say the least. not to mention lots of these games have zero
clue about handling multi-monitor correctly. having a wm that handles this well
already it's frustrating to say the least.

what YOU want is that focus and other thins are handled better when the app
just says "screw it" and goes override-redirect - or normally would go down
that path. imho what you really want is a new fullscreen mode (or an extra flag
property you can set while using the current fullscreen mode) to say "see the
window size i have, PLEASE try and use a resolution that is that exact size, or
find one as close to it as you can and then resize me".

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com