On Friday 26 October 2012 19:01:40 Carsten Haitzler wrote: > 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. :) cool for e17 that it's in the trivial bucket, but I think we have a different understand of what is trivial ;-) > > > 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! :) :-( but that really helps to know - as written somewhere in the thread: I'm not a gamer and I will probably just never understand the needs.
Attachment:
signature.asc
Description: This is a digitally signed message part.