The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
This is the beginning of a new testing era for KWin: finally we are
able to test against a running KWin. This works by making use of the
new virtual framebuffer backend for Wayland. It starts a specific
Application subclass which is mostly a fork of ApplicationWayland.
The individual tests are able to influence the socket name and the
size of the virtual screen. This is supposed to be done in
initTestCase. To know when KWin is fully started one can use the
workspaceCreated signal of KWin::Application. KWin is not started in
another process, but the kwin library is used, so the test has pretty
much full introspection to everything going on inside KWin. It can
access the Workspace, WaylandServer, fake input events through
InputRedirection and so on.
Once the test KWin is running it's possible to connect to it using
KWayland::Client library. This allows to introspect the Workspace
to see whether all worked as expected (e.g. correct stacking order,
active window and so on).
This first autotest is mostly meant to illustrate how to setup a
test and how one can use KWayland::Client to interact with the mock
KWin. For more tests it is suggested to move the connections to the
Wayland server in the init() and cleanup() methods.
The change also affects the qpa plugin: the specific check to only
run in binaries called kwin_wayland doesn't hold any more. This can
now be overwritten by an env variable.
Please note that this first test will probably fail in the CI system
as it might not have XWayland which is needed by KWin.
This introduces an own QPA plugin for KWin. QtWayland's plugin is not
a good solution for KWin as QtWayland is meant for Wayland clients and
not for a Wayland server. Given that it makes more sense to have a very
minimal QPA plugin which supports the use cases we actually have.
With our own QPA plugin we should be able to improve the following
areas:
* no need to create Wayland server before QApplication
* Qt::BypassWindowManagerHint can be supported
* no workaround for creating OpenGL context in main thread
* sharing OpenGL context with Qt
* OpenGL context for Qt on libhybris backend
The plugin supports so far the following features:
* creating a QPlatformWindow using KWayland::Client (ShellSurface)
* creating a QPlatformBackingStore using a ShmPool
* creating a QPlatformOpenGLContext with Wayland::EGL
* or creating a QPlatformOpenGLContext which shares with KWin's scene
* creating a QPlatformScreen for each KWayland::Client::Output
* QPlatformNativeInterface compatible to QtWayland