Re: Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE



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.



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