kwin_wayland has become unstable. Sometimes it works fine, sometimes it
is randomly killed. Things are quite bad after kwin_wayland --replace.
This reverts commit 71ade59f4b.
It makes code more intuitive, updating X11 specific stuff should not be
needed to update the grid layout. Another advantage that this change
brings is that it should be possible to decouple X11 bits from the
virtual desktop manager completely, might be useful for running multiple
xwayland instances.
The documentation of NETRootInfo::activate() says that it should be
called after creating the NETRootInfo object to read properties.
However, it's called in two places: VirtualDesktopManager::setRows()
and Workspace::initializeX11(). At quick glance, there's no justifying
reason to call activate() in setRows(), it doesn't fit the purpose
of setRows().
This change re-arranges NETRootInfo initialization code so it makes
more sense.
Allows to notify systemd whether kwin is still running and possibly
restart the service if it stops responding.
Use Type=notify-reload to watch the kwin service. This will make it so
we receive SIGHUP rather than SIGTERM on the wrapper which we can handle
gracefully and stop the kwin process and restart as expected.
https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
Signed-off-by: Victoria Fischer <victoria.fischer@mbition.io>
The current implementation of the `<N>` suffix is still buggy and its
benefits are doubtful. One could argue that visual aids such as window
thumbnails or highlighting the windows are better. On its own, these
numbers don't have strong connections to the windows and can change on
a whim.
This way no extra buffer space is going to be wasted for a decoration
that isn't there, and it might be nicer for fractional scaling as kwin
won't need to deal with border size voodoo cases.
This is because the Overview will activate itself at the end of a 1:1 gesture,
and a toggle action might actually deactivate it rather than activate it.
With how Xwayland scaling works, KWin assumes the window already uses the
new coordinate system - but that doesn't happen until Xwayland and the client
know about the new size as well.
BUG: 480642
The failure might be from the commit reordering going wrong in some way.
The total accumulated state might still work even if an individual commit
does not though, so before considering the whole frame lost, merge all the
commits and try again
This was just done because of the wrong assumption that displays needed that
to show the full native gamut. That turned out to be an amdgpu bug though; with
that fixed, most of the 0-100% range is wildly oversaturated.
To make the slider more intuitive, this changes the sdr gamut wideness to instead
interpolate to the native display primaries as indicated by the EDID.
The screencast plugin doesn't take into account the hidden status of
the cursor, which results in the cursor being visible when screencasting
even though it's hidden.
At the moment, the desktop layout in _NET_DESKTOP_LAYOUT overwrites new
desktop layout with outdated information. This happens because kwin tries
to honor the desktop layout set by the pager. However, kwin itself
already acts as the pager. The pager applet in plasma doesn't attempt to
maintain _NET_DESKTOP_LAYOUT with proper values.
On the other hand, kwin trying to both update and also sync its state to
_NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES has created a series of
issues, like lockups or rendering glitches.
Given that the window manager can ignore these properties, and the fact
that kwin already does act like a pager, this patch makes kwin ignore
external updates to _NET_DESKTOP_LAYOUT and _NET_DESKTOP_NAMES.
In order to modify the desktop layout on X11, use the dbus api. On
Wayland, either the dbus api or the virtual desktop wayland protocol.
BUG: 422319
BUG: 480371
Support is hidden by an environment variable to prevent accidental standardization
on this experimental version. It allows app devs to already implement and
test it though, and easily switch to the proper protocol later
A window is added to the workspace when it's mapped. It's assumed that
the first Window::windowShown signal indicates that. But it's not
entirely true. For example, if setHidden(false); setHidden(true); are
called in succession, the window will be marked as ready for painting
even though it isn't.
The Window::readyForPaintingChanged() signal fixes that. It's emitted
when the window is actually mapped.
