Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

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

On Fri, 26 Oct 2012 08:55:18 +0200 Martin Gräßlin <mgraesslin kde org> said:

> On Friday 26 October 2012 09:18:04 Carsten Haitzler wrote:
> > On Thu, 25 Oct 2012 19:40:49 +0200 Martin Gräßlin <mgraesslin kde org> said:
> > > On Thursday 25 October 2012 13:29:13 Ryan C. Gordon wrote:
> > > > > 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
> > > > doing that itself without any coordination with the system). I think
> > > > 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.
> > > > 
> > > > 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.
> > > > 
> > > > 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?
> > > 
> > > Honestly? No. That would be way too invasive change to the handling of
> > > KWin
> > > internals. E.g. we currently do not support changing the atom what KWin
> > > supports also to not handle the resolution change is not at all trivial.
> > 
> > errr... ummm... changing that property is a triviality... i fail to see how
> > you can "not support changing it" withotu actually going ot lots of effort
> > to make it not possible.
> Of course changing that property is a triviality, which doesn't change the 
> fact that right now in KWin we don't have a method to update the property. So 
> for the source base it's not a triviality and that's all I wanted to point 
> out. Implementing this proposal is not a trivial task at least for a window 
> manager like KWin. Of course it's all possible, but that doesn't mean it's 
> easy or will ever happen.

you have a blob of code that builds an array of property id's and then
calls the property set... simply making that a shared method/func or copy &
pasting will do the job. :) i'm curious what you level "of "not trivial"
is... :) from my pov... this feature is pretty easy to support in e17. we have
to add some logic to "suspend adapting to randr/root window/xinerama changes"
and double-check everyone is using the correct infra values (container/zone
values) and make an exception for this exclusive fullscreen window to use the
real screen values. other than that its just some randr fun that we already
have code for to switch resolution in (and back) and store it. :) i put that
under the "relatively trivial" bucket. :)

> Don't get me wrong: I'm all for improving the situation, I'm just someone who 
> is very sceptical and am looking for the best solution not from a theoretical 
> aspect but from a practical one. A few things I understand better now like
> why games change resolutions and I see that I can give up any hope for games
> doing that.

abandon all hope ye who enter here! :)

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