The Wayland::Registry class wraps wl_registry handling. It keeps track
of the interfaces in the registry and emits signals whenever a known
interface gets announced or removed. So far it only tracks the interfaces
which are used and needed by KWin.
The Wayland event queue is moved into a dedicated thread and a
new class is created for just creating the connection and listening
for events. The WaylandBackend creates the thread and uses an event
queue for the main thread.
REVIEW: 119761
KWin_Wayland still needs an X-Server. To simplify the development
setup the required X-Server can be started through a command line
argument together with KWin. Unfortunately the command line arguments
processing needs to be done by hand as QCommandLineParser only allows
processing after QApplication is created which requires the started
X Server.
The nested X-Server is started by forking the application and using
execlp to load the binary. In addition a pipe is created to allow the
X-Server to write the display number to once it's ready to connect and
by that KWin is ready to create the QApplication.
All of kwin except the main function goes into a new (private) library
called kwin. Two new kdeinit_executables are created:
* kwin_x11
* kwin_wayland
Both only use a dedicated main_x11.cpp and main_wayland.cpp with the
main function and a KWin::Application subclass and linking the new
kwin library.
The main idea behind this is to be able to perform more sane sanity
checks. E.g. on Wayland we don't need to first test whether we can
create an X11 connection. Instead we should abort if we cannot connect
to the Wayland display. Also the multi-head checks are not needed on
Wayland, etc. etc. As most of that code is in the main function to
simplify it's better to split.
This will also make it easier to diverge more easily in future. The
Wayland variant can introduce more suited command line arguments for
example. This already started by having the --replace option only
available in X11 variant. The Wayland backend is still a window manager,
but doesn't claim the manager selection.
Required to stop and disconnect the timer. Otherwise it's possible
that the render is invoked after the Client got destroyed. This
happened for example with e.g. opening Kickoff.
Uses the QuickTileMode of the Client to indicate which borders to
remove. This could be extended to be in general when a window borders
the screen edge and not just for quick tile mode.
So far the DecorationRenderer got destroyed and recreated after
the signal compositing toggled was emitted. But that's too late for
e.g. the OpenGL Textures to be destroyed. So lets trigger the destroy
directly in setup/finish compositing. The new renderer will still be
created after the compositing toggled is emitted - we don't want to
have it recreated for the still active compositer type.
