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.
The main advantage of SPDX license identifiers over the traditional
license headers is that it's more difficult to overlook inappropriate
licenses for kwin, for example GPL 3. We also don't have to copy a
lot of boilerplate text.
In order to create this change, I ran licensedigger -r -c from the
toplevel source directory.
Debugging the panel thumbnails I realised that the setPosition calls
didn't have an effect. This is probably not the only way to fix this bug
but does fix the bug.
At the moment it only brings the position from the interface.
Right now KWin moves minimized windows to the end of the task switcher's
ordering. However this is a rather confusing and undocumented behavior
that explicitly overrides the user's chosen sort ordering, be it
"Recently used" or "Stacking order". This makes it a hidden magic behavior
of the type that is at risk of being more annoying than useful.
This commit removes the special handling and lets minimized windows live
in the appropriate order in the task switcher.
Vlad Zahorodnii