So far, we were creating a model view with the complete scene rendered
(even if we didn't render the windows themselves). This required us to
have a big glPerspective spanning the entire scene and we were just
cropping it as we rendered it into a smaller texture.
This changes our scenes so we have the correct matrix set up at all
times.
Specifically in the case of the Pinephone, this solves the following
issue where we were unable to connect external displays because it
exceeded GL_MAX_VIEWPORT_DIMS:
https://invent.kde.org/teams/plasma-mobile/issues/-/issues/11
When the panel disappears, just reconsider the panel's state but don't
just stop sending updates to the input method.
Some input methods are just helpers that show and hide as necessary.
The Xrender backend was added at the time when OpenGL drivers were not
particularly stable. Nowadays though, it's a totally different situation.
The OpenGL render backend has been the default one for many years. It's
quite stable, and it allows implementing many advanced features that
other render backends don't.
Many features are not tested with it during the development cycle; the
only time when it is noticed is when changes in other parts of kwin break
the build in the xrender backend. Effectively, the xrender backend is
unmaintained nowadays.
Given that the xrender backend is effectively unmaintained and our focus
being shifted towards wayland, this change drops the xrender backend in
favor of the opengl backend.
Besides being de-facto unmaintained, another issue is that QtQuick does
not support and most likely will never support the Xrender API. This
poses a problem as we want thumbnail items to be natively integrated in
the qtquick scene graph.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
With the ongoing scene redesign, it needs to be rewritten. However,
given that it is not used widely based on support information from
various bug reports and our available man power is sparse, the most
reasonable thing is to drop the effect, unfortunately.
static cuts[] array was initialized only once with copies of non-const
objects, so when new shortcuts are configured, the old objects were still
referenced.
Fixed by having non-static array instead, so actual objects are copied
on the init every time.
BUG: 359141
Some static code analysis tools break when analysing kwinbindings.cpp.
This change moves the contents of kwinbindings.cpp file in useractions.cpp
to make those tools happier. It also makes code more readable.
The KCM now manages the RuleSettings config objects directly,
instead of using a list of `Rules` objects as an intermediary.
This highly reduces the overhead, improving loading and saving
times, and also enables a better use of KConfig capabilites.
The config state is now automatically tracked by KConfigXT
objects. Whenever the user edits either the rule list, or any
specific property within a rule, the `needsSave` state is
updated accordingly.
BUG: 421564
FIXED-IN: 5.23
Previously, the only way to access the rules list was via
the `rules()` and `setRules()` methods, so the actual
settings objects were not accesible.
This commit adds methods to retrieve, insert, remove or reorder
the rules within the list.
Since every individual rule is stored as a KConfig group, and
they are not designed to be dynamically renamed, using consecutive
numbered groups and store only the total count is problematic.
So we also add a new stringlist setting to store the rules group
names and their order.
Now any group name is valid. To avoid collisions use random QUuids
as group names for newly created rules.
Even though there is a clientArea() overload that takes const abstract
clients, QJSEngine seems to be unable to find the right clientArea()
overload if a mutable abstract client has been passed.
BUG: 437507
Currently, the frameRendered() signal is emitted every time an effect
calls paintScreen(). This means that the frameRendered() signal can be
emitted more than once when effects such as slide are active. However,
we'd like if it's emitted only once before buffers are swapped.
This allows different input methods to get information about what's
beign typed from the actual hardware. This is especially useful for
non-latin script languages.
If the user has chosen to have a virtual keyboard (i.e. prefered maliit
over none in the KCM) they should get it. If it's too annoying it should
either be disabled or we can fix it so it gets less in the way.
This is especially important since some hardware registers itself as a
keyboard even if it's not a fully functional keyboard.
EffectWindow::shape() doesn't fit the item based design. This change
ports the blur effect away from the shape() function to the rect()
function. The XShape extension was introduced when windows with an alpha
channel wasn't really a thing. Setting a shape served as a way to clip a
window, the most notable example is xeyes.
If an application relies on the xshape extension to actually clip the
window and not to force the window manager not to put the server-side
deco, it most likely doesn't support translucency and therefore it
shouldn't set the blur region to begin with.
This change makes the blur effect ignore the xshape region similar to
the background contrast effect. It allows us to decouple a bit more
effects from the rest of rendering machinery and thus make it easier for
us to move forward with the scene redesign goal.
We used to get a weird line around the window decoration because the
clamping would hit the outside of the rendered decoration.
To make sure we fall inside take the displayPixelRatio into account.
Also on non-integer scales, make sure we are actually falling inside.
