> On Nov. 17, 2015, 9:55 p.m., Daniel Vrátil wrote: > > src/backendmanager_p.h, line 130 > > <https://git.reviewboard.kde.org/r/126101/diff/1/?file=417202#file417202line130> > > > > Why is this even a QHash? We don't want to run multiple backends at > > once, or do we? Wouldn't just holding pointer to the current backend be > > enough? Maybe even without the arguments...
The arguments are needed for the Fake backend, otherwise, loading a different config doesn't work, which breaks a bunch of tests. Instead of shutting down the backend, it's enough to re-init() it, which is what I'm doing here. This bit could potentially make sense for other cases, for example passing the config for a wayland test server (which is what I'm doing for the wayland tests), and possibly also the WAYLAND_DISPLAY to use, as to avoid getting in the way of a running server. - Sebastian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126101/#review88502 ----------------------------------------------------------- On Nov. 18, 2015, 12:32 a.m., Sebastian Kügler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126101/ > ----------------------------------------------------------- > > (Updated Nov. 18, 2015, 12:32 a.m.) > > > Review request for Plasma, Solid, Àlex Fiestas, Aleix Pol Gonzalez, Daniel > Vrátil, and Martin Gräßlin. > > > Repository: libkscreen > > > Description > ------- > > This patchset adds in-process operation to libkscreen > > purpose: > - allow easier debugging > - for some backends (qscreen, upcoming kwayland) the out of process operation > is not necessary since these backends are well-shielded > > This implementation is backwards compatible and should mean only minimal > changes to running setups. > > If the user exports KSCREEN_BACKEND_INPROCESS=1 before running, all > operations will be done in process. Otherwise, the out-of-process mode is > used. > > The idea is that we use > The changes in the clients to use the in-process mode are to use > ConfigOperation::create() and ConfigOperation::setOperation() to retrieve the > get or set config jobs. The rest will be handled inside libkscreen. > > Autotests should cover all the cases (and actually a few currently > unsupported ones, such as using different backends in the same process). > > Details on performance, etc.: > http://vizzzion.org/blog/2015/11/wayland-and-libkscreen-benchmarks/ > > > Diffs > ----- > > CMakeLists.txt 86a0965 > autotests/CMakeLists.txt 69af7f0 > autotests/testconfigmonitor.cpp a051226 > autotests/testinprocess.cpp PRE-CREATION > autotests/testqscreenbackend.cpp da4dbae > autotests/testscreenconfig.cpp ecbcedf > backends/fake/fake.cpp 60264dd > src/CMakeLists.txt 4b56b61 > src/backendlauncher/backendloader.cpp 52051df > src/backendmanager.cpp ca9c746 > src/backendmanager_p.h c6418e2 > src/config.cpp 75d947d > src/configmonitor.h b6f1189 > src/configmonitor.cpp a14bc70 > src/configoperation.h 2405d79 > src/configoperation.cpp 87fe141 > src/getconfigoperation.h c85bfaa > src/inprocessconfigoperation.h PRE-CREATION > src/inprocessconfigoperation.cpp PRE-CREATION > src/output.cpp bd381fa > src/setconfigoperation.cpp 6ea944f > src/setinprocessoperation.h PRE-CREATION > src/setinprocessoperation.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/126101/diff/ > > > Testing > ------- > > Added a ton of autotests, made sure all existing ones pass. > > tried "KSCREEN_BACKEND_INPROCESS=1 kcmshell5 kscreen", all working as > expected. > > > Thanks, > > Sebastian Kügler > >
_______________________________________________ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
