We use the PMF syntax so the isValid() check is unnecessary as the
compiler will notify about wrong signal at compile time. It makes
writing autotests feel less boilerplaty.
Things such as Output, InputDevice and so on are made to be
multi-purpose. In order to make this separation more clear, this change
moves that code in the core directory. Some things still link to the
abstraction level above (kwin), they can be tackled in future refactors.
Ideally code in core/ should depend either on other code in core/ or
system libs.
The .clang-format file is based on the one in ECM except the following
style options:
- AlwaysBreakBeforeMultilineStrings
- BinPackArguments
- BinPackParameters
- ColumnLimit
- BreakBeforeBraces
- KeepEmptyLinesAtTheStartOfBlocks
These are two conceptually different tasks that were intertwined.
On it's own it doesn't accomplish anything but is an important refactor
for longer term goals, namely:
- moving xwayland into kwin_wayland_wrapper with our wayland restart
handling support
- having multiple X connections
Behaviour should be the same.
The Compositor contains nothing that can potentially get dirty and need
repainting.
As is, the advantages of this move aren't really noticeable, but it
makes sense with multiple scenes.
Backend parts are far from ideal, they can be improved later on as we
progress with the scene redesign.
When debugging modifier_only_shortcut_test in _waylandonly mode I saw
that it was failing, among other things, because some aspects were not
initialised.
This changes every test we have to run the new
Test::initWaylandWorkspace() that calls waylandServer()->initWorkspace()
but also makes sure that WaylandServer::initialized is emitted before we
proceed.
A window id generated by WaylandServer may reference an X11 window
with the same id, which can result in undefined behavior.
The main reason why we needed windowId() was because of the task
switcher. However, since tabbox uses internal ids now, the window id
property can be dropped.
If Xwayland has crashed, the Workspace will block stacking order updates
and start destroying all X11 clients.
Once stacking order updates are unblocked, the Workspace will mark the X
stacking order as dirty and create a new Xcb::Tree object.
We don't want to create that Xcb::Tree object because accessing it
after the XCB connection has been shut down will lead to a crash.
BUG: 427688
FIXED-IN: 5.20.1
If the Xwayland process has crashed due to some bug, the user should
still be able to start applications in Xwayland mode. There is no reason
to restart the whole session just to be able to launch some application
that doesn't have native support for Wayland.
