> On Jan. 6, 2016, 2:59 nachm., Kai Uwe Broulik wrote: > > src/inhibition.cpp, lines 38-40 > > <https://git.reviewboard.kde.org/r/126650/diff/1/?file=428573#file428573line38> > > > > initializer list? > > > > Private() > > : status(Inhibition::Inactive) > > , ... > > > > Also, you're leaving most member variables uninitialized > > Martin Klapetek wrote: > Is there any actual difference (performance or something) between setting > the values in ctor and setting them before ctor?
Depends on the type, iirc for non-integral types they'll be default-constructed just to immediately get assigned a proper object in the constructor's body. - Kai Uwe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126650/#review90697 ----------------------------------------------------------- On Jan. 6, 2016, 7:17 vorm., Martin Klapetek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126650/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2016, 7:17 vorm.) > > > 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
