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.
The region that we pass to the next paintWindow() cannot be larger than
the one that we've received. If an effect passes a larger region, the
tracked buffer damage will be messed up and user will see all sorts of
visual artifacts.
The results of the blur and the background contrast effect will never
be seen if the screen locker is active.
In order to avoid wasting computational resources, we could temporarily
disable the blur effect until the screen is unlocked.
Furthermore, given that the blur effect shrinks the clip region, it is
guaranteed that the compositor will have to render the desktop window
behind the lockscreen window. With this change, all windows behind the
screen locker will be properly clipped away.
The original purpose of m_damageArea was to indicate which region of the
blur cache became dirty and needs to be updated. However, we no longer
need to keep track of damaged area since the blur cache was removed.
This adds a setting to the window options KCM to disable KDE apps
remembering their own window positions on X11, and instead always use
the KWin placement modes.
The setting sets an option in `kdeglobals`, rather than kwinrc, as it is not
a KWin-specific option *per se*. The UI is also hidden on Wayland, as it it
not relevant there because the functionality it disables does not work on
Wayland. Instead, remembering window positions will eventually be implemented
in a different way and affect all windows, not just KDE windows.
See https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/14 for
more details.
CCBUG: 415150
Toplevel::debug() is one of annoyances that you need to deal with when
implementing a new client type. It can be tempting to just write "this"
to the stream, but it will result in a crash.
In order to make implementing new client types easier, this change
introduces a debug stream insertion operator overload that works for all
kinds of the Toplevel class.
This change adds a default handle for screen edge based activation in
order to reduce the amount of boilerplate in client sub-classes that do
not support features such as auto-hiding, e.g. popups.
This change adds a default implementation for no border functionality
in order to reduce the amount of boilerplate code in client sub-classes
that have no support for server-side decorations.
Not all client types support server-side decorations, for example it's
typically the case for popup windows. This change provides a default
implementation for the updateDecoration() method in order to reduce the
amount of boilerplate code in client types that have no support for ssd.
Currently, we have two functions that update the color scheme for a
client - updateColorScheme(QString) and updateColorScheme(). Even though
they both share the same name, they do different things. The first one
sets the specified color scheme, while the other determines the color
scheme preferred by the client and assigns it.
This change refactors the color scheme initialization code so we no
longer need those two methods. The setColorScheme() method sets the
specified color scheme, and the preferredColorScheme() method returns
the color scheme preferred by the client. Sub-classes of AbstractClient
can override the preferredColorScheme() method in order to add support
for platform-specific color scheme protocols.
The end result: color scheme related code is a bit more comprehensible.
Summary:
Notify the driver about the parts of the screen that will be repainted.
In some cases this can be benefitial. This is especially useful on lima
and panfrost devices (e.g. pinephone, pinebook, pinebook pro).
Test Plan:
Tested on a pinebook pro with a late mesa version.
Basically I implemented it, then it didn't work and I fixed it.
Maybe next step we want to look into our damage algorithm.
This change upstreams window hiding functionality from the XdgSurfaceClient
class to the WaylandClient class in order to reduce the amount of duplicated
code in new wayland client sub-classes.
It is a very privacy-concerning component, so we will treat it
specifically.
As it is, it will have to come from the --inputmethod argument. We can
work on some UI later on to select which keyboards are available.
Vlad Zahorodnii