Non-current output modes were deprecated due to various reasons, e.g.
it's not possible to remove some nodes; two modes can have the same
resolution and the refresh rate but different flags, but wl_output.mode
fails to communicate that properly; the usefulness of non-current modes
is questionable. For more details, please refer to [1].
[1] https://gitlab.freedesktop.org/wayland/wayland/-/issues/92
This rewrites the wl_seat protocol implementation to adhere to the new
design principles.
Effectively, we've been supporting wl_seat v7 so the version was also
bumped from 5 to 7.
The main reason why we have factory methods is that up to some point,
kwayland had its own signal to indicate when globals have to be removed.
Now that all globals add destroy listeners for the wl_display object,
we don't have that signal. Most factory methods are equivalent to doing
new T(display).
Besides adding unnecessary boilerplate code, another reason to get rid
of the factory methods is to reduce the amount of merge conflicts. If
several persons work on implementing wayland protocols at the same time,
sooner or later someone will have to resolve merge conflicts in Display.
The current xdg-shell wrappers don't match existing abstractions in the
xdg-shell protocol well, which makes it more difficult to refactor code
that is responsible for managing configure events and geometry in kwin.
Given that the xdg_decoration and the xdg_shell protocols are tightly
coupled together, I had to rewrite our wrappers for the xdg_decoration
protocol as well.
wl_shell_surface has been deprecated for quite a long time. Nowadays
most clients use the xdg-shell protocol to create desktop-style user
interface elements.
This change demonstrates how one can install a custom event dispatcher
before creating the QGuiApplication and how to process Wayland events
using the event dispatcher to e.g. start an Xwayland server prior to
creating the application.
It also allows to use
--platform wayland
on the test application. The wayland QPA plugin will connect to the
KWayland server started prior to creating the application.
Please note that such a setup will freeze unless QtWayland has commit
1e32e71 [1].
[1] 1e32e71403
Instead of performing dispatchEvents for a hard coded number of
expected events from Xwayland, we use select on the pipe to figure
out whether Xwayland has started writing the display number. As long
as select does not indicate that the pipe is ready we need to dispatch
further events.
Proof-of-concept code illustrating how to start a Wayland server
before creating the QGuiApplication and also starting an Xwayland
server before creating the QGuiApplication. Thus the QGuiApplication
is able to connect to the Xwayland server started in the same
application.
