Window quads need to be in some coordinate space. Since we want items to
be used not only for rendering windows, window-local coordinates do not
suffice.
This change makes scene items generate quads in the item-local coordinate
space.
The model matrix is used to map the quads to the global screen coordinate
system from the item coordinate space.
Since the quads are in the item local coordinate space, the mvp matrix
needs to be updated on every draw call. Given the render data, tracking
the last mvp matrix won't result in less glUniform calls. If this indeed
becomes a serious performance bottleneck, we can explore the possibility
of dumping mvp matrices in a UBO, which have been introduced in OpenGL
3.1.
The scene items depend on the scene windows for caching window quads.
The goal of this change is to move window quads management to item.
Merging window quads in one list and then splitting them is inefficient,
it will be highly desirable if window quads are removed from the public
api so we can optimize window quad management.
With this change, the window quad type becomes irrelevant to render
backends for the most part. Note that the Xrender backend is a bit
nitpicky about window quads, so the shadow item doesn't create generic
"WindowQuadShadow" quads anymore.
Drop-shadows with the software render backend impact performance quite
significantly. It also makes it easier to prepare render backends for the
item based design.
Use FontMetrics to calculate the expected max text width so it
doesn't overflow with wider fonts, specially in some languages
like pt_BR
BUG: 438193
FIXED-IN: 5.22.1
Offers shoul be set on a source before data_device.set_selection. Doing
so afterwards appears to be against the spec and as such we may not pass
the update to wayland clients / klipper.
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
