Review Request 115137: Provide information about the active screen in KWindowSystem

Thomas Lübking thomas.luebking at gmail.com
Thu Jan 30 18:02:57 UTC 2014 


> On Jan. 20, 2014, 5 p.m., Thomas Lübking wrote:
> > given the ratio by this property is set (often) and read (rarely), i wonder whether we could establish a semi-async functionality, where the client sends a message to have the property updated, then syncs, reads and returns the updated property?
> > 
> > reg. screen ./. output terminology:
> > we've "active screen" everywhere and we can probably not expose the screen/output problem to end users.
> > Also Qt talks of screen in this regard.
> > I'd suggest to keep activeScreen and specify the meaning in the comment.
> >
> 
> Martin Gräßlin wrote:
>     > i wonder whether we could establish a semi-async functionality, where the client sends a message to have the property updated, then syncs, reads and returns the updated property?
>     
>     That would be different to how all the other methods in KWindowSystem works. What could be considered is not having a signal to not wake up the clients or only emit the signal if connect-notify is called.
>     
>     > Also Qt talks of screen in this regard.
>     
>     This was the reason why I went with screen in the first place. The class is called QScreen and not QOutput. Calling it output didn't occur to me at all. I don't mind how it is called and from a technical perspective (especially considering XRandR) I agree with Fredrik. But from a user point of view I think screen is the better name due to the QScreen anology. What could be done is using output in the NET class to be closer to the X11 world, but keep the name screen in the abstraction. I don't know whether output makes sense on Windows or Mac (in case they ever implement it).
> 
> Thomas Lübking wrote:
>     > That would be different to how all the other methods in KWindowSystem works.
>     My major concern would be the mouse driven active screen.
>     Right now, when the active screen is required, kwin just checks the current mouse position.
>     When we need to keep the info updated (signal or not), that means that kwin has to poll the mouse all the time (even if we would "smoothen" the update by a timer so the active screen isn't updated a 1000 times when moving the cursor around a screen edge).
>     
>     And while knowing the "active" screen is certainly nice, our main concern right now is the occasional raiseOrLower taskbar case.
>     
>     A 2-pass query would nicely circumvent this as the data only needs to be updated when really and likely rarely required.
> 
> Fredrik Höglund wrote:
>     kwin should be using XI2 instead of polling.
>     
>     We already have properties that are updated every time the stacking order changes
>     and every time the active window changes.  Given that, I don't think the update
>     frequency for this property is going to be a problem.
>     
>     So with regards to the terminology, this is what we're looking at:
>     
>     X               | Qt
>     ----------------+-----------------
>     Output          | Screen
>     Screen          | Virtual desktop
>     Virtual desktop | ?
>     
>     Which is just really unfortunate.  It's bound to cause confusion no matter
>     which name we pick, and it doesn't help that the QScreen documentation
>     doesn't explain the terminology.
>     
>     Windows and Wayland also use "output", while I think Mac OS uses "display".
>

> kwin should be using XI2 instead of polling
yes, "should" - https://git.reviewboard.kde.org/r/111875/


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115137/#review47824
-----------------------------------------------------------


On Jan. 20, 2014, 1:14 p.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115137/
> -----------------------------------------------------------
> 
> (Updated Jan. 20, 2014, 1:14 p.m.)
> 
> 
> Review request for KDE Frameworks, kdewin and kwin.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> -------
> 
> The rational for these changes is based on the discussion in http://article.gmane.org/gmane.comp.kde.devel.plasma/27579/
> 
> Plasma needs to know which is the active screen and so far only KWin knows it, so we need to make everybody aware of it.
> 
> ---
> Add convenient wrapper for active screen to KWindowSystem
> 
> A method is added to get the identifier of the active screen as a
> QString and a signal whenever the active screen changes. This method
> is only provided for X11, on Windows and Mac a null QString is returned
> as the identifier.
> 
> Add an active screen property to NETRootInfo
> 
> The active screen is intended to be set by KWin to the active screen
> it's using. This can be used by a Client to manually position e.g.
> override redirect windows on the active screen. It's intended as a help
> for multi-screen setups where a Client can only do guesses on where to
> position e.g. a notification window.
> 
> It's a KDE specific extension as property _KDE_NET_ACTIVE_SCREEN and
> announced in the supported properties.
> 
> 
> Diffs
> -----
> 
>   autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 
>   src/kwindowsystem.h 5bcfd062dcca42d282b70d0683d4ee1da88cc814 
>   src/kwindowsystem_mac.cpp 8bd2ac763fa26ba49e7733fc3ba93e755383928c 
>   src/kwindowsystem_win.cpp 96148b2d808396a3046204e55fd19d767db017c5 
>   src/kwindowsystem_x11.cpp 8634240cabc708a608277b34f21c41cee295e48a 
>   src/netwm.h aee6cea5e3b65cf6252b50515e4920cb9c96f240 
>   src/netwm.cpp 266afccaf111e6707493b18dad1d9c03dde1d912 
>   src/netwm_def.h 8b1ccb8bd731aefb9559c8f2b450337b0312ed4d 
>   src/netwm_p.h 41792b330f7405034f4d51fb31a4de5dd674b6d0 
> 
> Diff: https://git.reviewboard.kde.org/r/115137/diff/
> 
> 
> Testing
> -------
> 
> * wm part of NETWM is unit tested
> * KWindowSystem is only compile tested (unit testing is difficult as we need a window manager which supports this property which is at the moment of this writing: none)
> * Windows and Mac is not even compile tested, that's why kdewin is included in the review. If you have the time for it, please do a compile test.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140130/bb3ed5e0/attachment.html>

More information about the Kde-frameworks-devel mailing list