A new implementation of the Screens interface is added which uses XRandR
directly instead of relying on QDesktopWidget. The implementation is
provided in a new implementation file screens_xrandr.cpp.
XRandRScreens comes with a unit test. Unfortunately it's rather difficult
to provide a proper unit test against XRandR. Xvfb (which is obviously
used on the CI system) doesn't provide the XRandR extension. Also on a
"normal" developer system one would not want to just execute the test as
the results are not predictable (number of available outputs?) and the
test would mess up the setup resulting in nobody wanting to execute the
test.
As a solution to both problems the unit test starts Xephyr as a nested
X server. This allows to have at least some limited tests against XRandR.
Nevertheless there are a few things which I was not able to test:
* multiple outputs
* no output at all
The nested X Server approach makes the interaction rather complex. Qt
opens it's connection against the main X Server thus QX11Info provides
a wrong connection and also KWin::connection() which is heavily used by
xcbutils and thus all the RandR wrappers have the wrong connection. To
circumvent this problem the test is GUILESS. In case it would call into
any code using QX11Info, it would probably either runtime fail or crash.
REVIEW: 117614
The new test does not cover ScreenEdges completely, so far the
following areas are handled:
* creating of the edges
* reserving of edges
* trigger callback
* cursor pushback
* blocking of edges for fullscreen active clients
This is a very interesting auto test as Screens uses both Workspace
and Client. Thus it operates in the "impossible to mock" area.
The solution is to provide mock includes in autotests and ensure that
when building the auto-test the mock header includes will be picked
first. There is now a mock class for Workspace and Client providing
just the API pieces used inside Screens.
As Screens is abstract and we cannot properly interact with
QDesktopWidget there is also a MockScreens class inheriting from Screens
and mocking the required functionality (by just operating on a list of
QRects).
The auto-test itself is only performing checks on the abstract class.
The mock class is indirectly tested by Screens calling into the virtual
methods. The test case is not yet complete, but looking quite good
already.
Martin Gräßlin