> 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).
> 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. - 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