Review Request 119822: QScreen backend for libkscreen

[Àlex Fiestas]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119822/#review64727
-----------------------------------------------------------


Besides the nitpits, here is a concern I have.

KScreen is a library that should be used only by components of the shell (kwin, plasma, kscreen), the idea is to have a library that manipulates lowlevel stuff directly so we can control how we do things (events and what not). Because of this having a qscreen backend enabled by default (even if it is only in platforms where we don't have a backend) imho is a no-go. We can't relay on abstractions.

That said, I do think that having a qscreen backend is an excellent fallback to test the shell in non supported platforms while we develop a proper backend, but we have to find a way of doing so qscreen backend is not used by accident.

To archieve this I see 2 options:
1-Load qscreen backend only via KSCREEN_BACKEND env
2-Improve backendloader and backends to make sure we use the proper backend in every case.

I think I will go for 1 at the moment, and we can figure out how to do the backend loading later on.

What do you think?


autotests/testqscreenbackend.cpp
<https://git.reviewboard.kde.org/r/119822/#comment45277>

    If we don't have a config even though we correctly configured the backend, should not we fail? a QSKIP might be unnoticed (specially in jenkins).



autotests/testqscreenbackend.cpp
<https://git.reviewboard.kde.org/r/119822/#comment45278>

    Q_FOREACH



autotests/testqscreenbackend.cpp
<https://git.reviewboard.kde.org/r/119822/#comment45276>

    Shouldn't it be qscreen? also, why the conditional at all?



backends/qscreen/CMakeLists.txt
<https://git.reviewboard.kde.org/r/119822/#comment45279>

    Is X11 used in qscreenbackend?



tests/testpnp.cpp
<https://git.reviewboard.kde.org/r/119822/#comment45280>

    Why is this tool needed at all? Also the copy pasted code is a no-go we should find a better solution, for example implementing streams on each object so we can simply do qDebug() << config


- Àlex Fiestas


On ago. 18, 2014, 9:31 a.m., Sebastian Kügler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119822/
> -----------------------------------------------------------
> 
> (Updated ago. 18, 2014, 9:31 a.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: libkscreen
> 
> 
> Description
> -------
> 
> This patch adds a QScreen backend to libkscreen.
> 
> This is useful to avoid a dependency on XRandR (at build time) and a running X server at runtime.
> 
> The backend itself is read-only and kept simple. It only reports the basic necessities (which is what QScreen provides).
> 
> The changes are kept to the backends/qscreen directory, so no API has been touched. The changes outside of that directory are autotests, tests, and a fallback to the qscreen backend non non-X11 platforms. The latter will automatically make libkscreen work on Wayland (as far as QScreen allows us to, so r-o). This case otherwise just crashes, and the XRandR backend can't work. If the user specifies the backend using the KSCREEN_BACKEND env var, it will be respected, the automatism only triggers when no backend is explicitely specified. I've also added apidocs in some files, but again, no functional changes.
> 
> The plan is to augment this also with a native Wayland backend, which will take a bit longer to complete (more complex, it's r-w, I have to learn Wayland APIs). That backend is work-in-progress in the sebas/wayland branch. The QScreen backend allows us to test and run our code under Wayland, without crashing, so we can continue the port while a native Wayland backend is conceived.
> 
> You can find the code for this QScreen backend in sebas/qscreen if you'd like to give it a try.
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt 18b93c0 
>   autotests/testqscreenbackend.cpp PRE-CREATION 
>   backends/CMakeLists.txt a827ee8 
>   backends/abstractbackend.h 7ffe627 
>   backends/qscreen/CMakeLists.txt PRE-CREATION 
>   backends/qscreen/qscreenbackend.h PRE-CREATION 
>   backends/qscreen/qscreenbackend.cpp PRE-CREATION 
>   backends/qscreen/qscreenconfig.h PRE-CREATION 
>   backends/qscreen/qscreenconfig.cpp PRE-CREATION 
>   backends/qscreen/qscreenoutput.h PRE-CREATION 
>   backends/qscreen/qscreenoutput.cpp PRE-CREATION 
>   backends/qscreen/qscreenscreen.h PRE-CREATION 
>   backends/qscreen/qscreenscreen.cpp PRE-CREATION 
>   src/CMakeLists.txt 4606862 
>   src/backendloader.cpp d6ccdff 
>   src/config.h 10a8f1e 
>   tests/CMakeLists.txt 86efedc 
>   tests/testplugandplay.cpp PRE-CREATION 
>   tests/testpnp.h PRE-CREATION 
>   tests/testpnp.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119822/diff/
> 
> 
> Testing
> -------
> 
> * Ran autotest "testqscreenbackend" under X11 and Wayland -- all pass
> * Tested hotplugging (using included testpnp app) under X11
> * Started plasmashell with KSCREEN_BACKEND=QScreen under X11
> * Started kcmshell5 kcm_kscreen
> 
> All of these work correctly in my tests, no strange behaviour observed.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140818/67aeddaa/attachment-0001.html>