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. 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. Cheers Martin Gräßlin
Attachment:
signature.asc
Description: This is a digitally signed message part.