Re: New Fullscreen Window Method

["Karl F. Glatzer" <karl glatzer gmx de>]

The first problem you mentioned isn't what I wanted to solve with this
proposal but it certainly would be nice if it could fix it, too. Thanks
for mentioning this.

The second problem you mentioned is what this is aimed at and it mostly
is not the WMs fault but the fault of the applications. So far
suppressing auto-hide panels is still wanted as long as the window is
focused since I wouldn't know how to reliably determine if showing them
is wanted or not. This decision could still be left to the WM and not
explicitly handled in the spec though.

The actual cases that I had in mind are games and a few other programs
that need resolution changes. Certainly advanced slideshow programs and
fullscreen videos benefit from this as well.

Am 03.02.2012 11:54, schrieb Giles Atkinson:
> After reading Karl's proposal, and the mailing list discussion linked from it, and Carsten's reply, I am still not clear what problem we are trying to solve.
> 
> There are two problems that I see with the existing full-screen mechanisms:
> 
> 1) There is no way to ensure that a window initially appears in full-screen state, causing flicker on initial mappings and complexity in the application.
> 
> This problem exists for all the window states, and the "fullscreen monitors" protocol.
> For the states the spec says: "The Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn window requests to be mapped. A Client wishing to change the state of a window MUST send a _NET_WM_STATE client message to the root window ...".  That SHOULD ought to be a MUST.  When I last looked at this it seemed to be widely ignored, and as WMs quite reasonable tend to ignore client messages for withdrawn windows, it seems necessary to wait for the window to be mapped before requesting full-screen and monitor spanning.
> 
> 2) Although the spec says nothing to suggest it, WMs and "desktops" tend to interpret the full screen state as implying some or all of: always on top; auto-hide panels suppressed; always focused; and not iconisable, even by shortcut.  This looks as unwanted for SDL games as for my application, so perhaps is similar to Karl's issue.  One way to fix it would be to introduce a separate "Presentation Mode" state for this behavior.  The cases where this would be wanted are (I think) slideshows and full-screen video.
> 
> Karl, do either of these relate to your problem?
> 
> Thanks,
> 
> Giles
> 
> -----Original Message-----
> From: wm-spec-list-bounces gnome org [mailto:wm-spec-list-bounces gnome org] On Behalf Of Carsten Haitzler
> Sent: 03 February 2012 04:00
> To: Karl
> Cc: WM-Spec Mailing List
> Subject: Re: New Fullscreen Window Method
> 
> 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".
>