Re: New Fullscreen Window Method

[Lubos Lunak <l lunak suse cz>]

On Friday 03 of February 2012, Giles Atkinson wrote:
> 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.

 No, it ought not. If a WM does not implement e.g. shading, then it's free to 
ignore it, because it can't do anything else anyway. Even if it does 
implement it and decides it is not suitable for whatever reason, it still 
should be free to do what is sensible and not whatever a random app thinks is 
the best idea in its limited view of the world. If apps could decide what 
goes on on the desktop, there'd be no point in having a window manager in the 
first place.

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

 I'm pretty sure KWin immediatelly makes windows fullscreened if they request 
it during mapping, and if not, then it's a bug. It's a bug as well if any 
other WM does not do that (or, alternatively, it's a deliberate choice, 
either way, there's no point having in a spec trying to work it around).

-- 
 Lubos Lunak
 l lunak suse cz