Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

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

On Thu, 25 Oct 2012 13:29:13 -0400 "Ryan C. Gordon" <icculus icculus org> said:

> 
> > Also in the case of KDE Plasma Workspaces the window manager is not at all
> > responsible for handling the resolution. This is done by a daemon called
> > krandr. I will not add code to change the resolution as that is nicely
> > handled by krandr. So we would need to announce the support only if the
> > daemon is present - this is something we would most likely not be able to
> > guarantee correctly as in session start KWin should be started before
> > krandr and it's possible that KWin is run outside a KDE Plasma session.
> 
> To be clear, I don't think _any_ window manager currently has code to 
> change resolutions (indeed, the core of the problem is that the app is 

correction here... E17 does. :) it has code to brush your teeth too. :)

> doing that itself without any coordination with the system). I think 

bingo. and of course this messes stuff upp as resolution changed for EVERYONE
as if the3 user just manually changed resolution. no one knows the
difference. :)

> it's great that KDE has a clear chain of responsibility for who is 
> allowed to interact with XRandR, which means this can be cleaner for you 
> than it might be for, say, Gnome.

for E17 the chain is clear. the wm is responsible. and in kde this isn;'t a
problem either (exposing fullscreen req to the wm) because kwin can PASS the
request off to the krandr infra... and now when resolution changes it KNOWs why
and can AVOID changing window layout to adapt to screen resoltuion EXCEPT for
the window that requested it. thus all the plasma gadgety things can stay in
their current layout. this gives kde the opportunity to "not mess up" in thsi
case. without this... it will always and forever "keep messing up" as games
(eg that use SDL) will keep using randr to change resolution themselves. :)

> How I would envision this working is something like this (I have no 
> experience with KDE source code, so this might be pure fantasy on my 
> part)...
> 
> - krandr sends a notification to KWin once it starts up, and then KWin 
> can begin advertising the appropriate atoms. If a fullscreen app wants 
> to start up in the very first seconds of the KDE session: too bad, but 
> if we're being really fancy, KWin could stall that app until krandr is 
> ready.
> - If you run KWin outside of a Plasma session--and therefore never have 
> krandr--KWin never advertises the atoms and never supports the 
> extension. That's what you get for not running KDE the way God intended.  :)
> - An app requests the _NET_WM_STATE_FULLSCREEN_EXCLUSIVE atom, KWin asks 
> krandr to change resolutions, and does NOT resize any of the windows or 
> move around desktop icons (etc) when it gets the resolution change 
> event. It makes the appropriate window the top of the Z-order, etc. 
> Other apps have no idea anything has changed for the most part.
> - When the window loses focus (user alt-tabbed out of the game, window 
> is legitimately being destroyed, etc), repeat this process, telling 
> krandr to return to the original resolution.

bingo. :)

> I'm ignoring some of the minutiae here, but that's the basic gist of it. 
> Does this sound like a reasonable approach for KWin?
> 
> --ryan.
> 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> https://mail.gnome.org/mailman/listinfo/wm-spec-list
> 


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