> On Jan. 11, 2016, 9:12 a.m., Martin Gräßlin wrote: > > I'm interested in the reasoning why to put it into KIdleTime? My first > > thought would have been Solid, so I'm interested in the reasoning.
It was suggested in the original review (https://git.reviewboard.kde.org/r/126627/), it's basically because all that this is inhibiting has to do with idle time detection, so it kinda fits into KIdleTime. Also since this is rather simple thing (just a couple of dbus calls), it's preferred to be in a smaller, tier1~ish library. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126650/#review90867 ----------------------------------------------------------- On Jan. 6, 2016, 8:17 a.m., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126650/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2016, 8:17 a.m.) > > > Review request for KDE Frameworks and Kai Uwe Broulik. > > > Repository: kidletime > > > Description > ------- > > This is a work-in-progress, but I'm putting it up for a feedback now > as most people are gone for the day when I wake up :) > > --- > > After some discussion in https://git.reviewboard.kde.org/r/126627/ > and then with Kai Uwe Broulik, I've added a PM/ScreenSaver inhibition > capabilities to KIdleItem. > > We decided with Kai that we want simple stuff, encapsulated away for > the client as much as possible. So the Inhibition class has a static > "constructors" which make the usage as easy as follows: > > KIdleTime::Inhibition::createInhibition(KIdleTime::Inhibition::InhibitScreen, > QStringLiteral("Playing Movie"), mainWindow); > > That call would return an Inhibition* object which has methods to set > the inhibition type and reason and to activate/deactivate the inhibition. > The static method above would activate() on the Inhibition right away; > this allows a simple fire-and-forget usage. The Inhibition object can > be parented to any other object; the inhibition will be deactivated when > the Inhibition object is destroyed. The user can also keep the pointer > around and call deactivate() whenever actually needed. > > The inhibition itself first looks for Solid and if present, it uses the > Solid interface. If not present, it goes for the FDO interfaces. > > It comes with an autotest. > > > Diffs > ----- > > autotests/qtest_dbus.h PRE-CREATION > src/CMakeLists.txt 23e5e29 > autotests/inhibition_test.cpp PRE-CREATION > autotests/CMakeLists.txt PRE-CREATION > autotests/fakePMServer.h PRE-CREATION > src/inhibition.cpp PRE-CREATION > src/inhibition.h PRE-CREATION > autotests/fakePMServer.cpp PRE-CREATION > CMakeLists.txt ed5dc0c > > Diff: https://git.reviewboard.kde.org/r/126650/diff/ > > > Testing > ------- > > Everything works as expected, plus there's an autotest. > > > Thanks, > > Martin Klapetek > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
