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.
It was needed to work around visual glitches in the wobbly windows
effect. Since the wobbly windows effect renders the animated window into
an offscreen texture, we don't need this workaround anymore.
Furthermore, rather than using half-pixel correction, it is more
desirable to use an offscreen texture as it results in simpler design.
Performance-wise, it's not that bad that we need to start looking for
other ways to get rid of the seams between window contents and deco.
DeformEffect is the base class for effects that transform the window
quad grid, e.g. wobbly windows or magic lamp. The main difference
between normal effects and offscreen effects is that the latter renders
animated windows into offscreen textures which are later deformed.
The offscreen texture approach is superior to the half-pixel correction
approach as it produces more visually appealing results. Even with
half-pixel correction, you're still going to see jagged lines between
the main surface and the server-side decoration or drop-shadow.
It is also needed to reduce the number of usages of WindowPaintData::quads
which is needed to move forward with the scene redesign goal.
If the window borders change in such a way that the buffer geometry
doesn't change, but the client geometry does change, we need to configure
the wrapper window and maybe the client window so there are no black
borders, etc.
Currently, there is an assumption in the moveResizeInternal() method
that if the buffer geometry changes, then the client geometry will also
change. However, as it turns out, it's not completely true. For example,
if the window is maximized while its geometry already matches the
maximize area, the buffer geometry won't change, but the client geometry
will change.
This change adds missing geometry checks. *geometryBeforeBlocking
corresponds to the old geometry. We can use it to decide if the geometry
has changed.
