Re: Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]