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.
This can be used to avoid code duplication by installing an effect multiple
times and tweaking behavior slightly based on the returned ID.
Internally it is called `scriptName` but for consistency with other similar
APIs the name `pluginId` is chosen, and returns e.g. `kwin4_effect_maximize`
With the DataBridge being a native event filter, we can further separate
DataBridge-specific and generic Xwayland bits. In particular, we no
longer have to call DataBridge::filterEvent() from the dispatchEvents()
method, whose main purpose is to dispatch X11 events to kwin.
Sometimes when a user puts the pen down too fast a TabletPress event will get triggered before a TabletMove event can occur. The app then assumes the user moved the pen very fast to the new position. The old position is there either (0,0), which often triggers the menu, or the last position the app received, which triggers apps like Xournal++ and Krita to paint a line from the old to the new position.
