> 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
