With the new compositing scheduling, we want the screen to be redrawn as
close as possible to the next vblank. Furthermore, compositing is no
longer driven by a timer. This change removes the NoSwapEncourage swap
strategy as it doesn't make sense now, in addition to that it just does
not work on Wayland.
At the moment, our frame scheduling infrastructure is still heavily
based on Xinerama-style rendering. Specifically, we assume that painting
is driven by a single timer, etc.
This change introduces a new type - RenderLoop. Its main purpose is to
drive compositing on a specific output, or in case of X11, on the
overlay window.
With RenderLoop, compositing is synchronized to vblank events. It
exposes the last and the next estimated presentation timestamp. The
expected presentation timestamp can be used by effects to ensure that
animations are synchronized with the upcoming vblank event.
On Wayland, every outputs has its own render loop. On X11, per screen
rendering is not possible, therefore the platform exposes the render
loop for the overlay window. Ideally, the Scene has to expose the
RenderLoop, but as the first step towards better compositing scheduling
it's good as is for the time being.
The RenderLoop tries to minimize the latency by delaying compositing as
close as possible to the next vblank event. One tricky thing about it is
that if compositing is too close to the next vblank event, animations
may become a little bit choppy. However, increasing the latency reduces
the choppiness.
Given that, there is no any "silver bullet" solution for the choppiness
issue, a new option has been added in the Compositing KCM to specify the
amount of latency. By default, it's "Medium," but if a user is not
satisfied with the upstream default, they can tweak it.
Add the activities info to the list of properties provided by
the `queryWindowInfo()` dBus method, and suggest them to the
user when inspecting a given window.
An empty activity list means "All Activities" (null UUID)
Also get the null UUID value instead of having it hardcoded.
This convenience invokable method was removed in 66ee89855
by mistake, since it's still used in RulesEditor.qml
While at it, optimize arguments to const &
Change the default value from "Do Not Affect" to "Apply Initially" when
adding new properties in Window Rules.
REASON: prior "Do Not Affect" as default and occasionally I forget to
change the setting to something else when adding new properties.
Unfortunately, this means I forget to do it and so it isn't saved when
I close the window. I will then go back in to change it to Apply Initially
or in some cases have to add the new property again as it wasn't saved in
the set.
I think if Apply Initially were to be the default it would be an easier
and faster experience to add new properties.
Fix Rendering backend combobox that was not highlighted.
Particular case due to OpenGLIsUnsafe kcfg entry which is an indicating
flag and not a configurable setting.
This reverts commit bcba2e252f.
This change broke a dozen of tests, most of which were fixed. However,
it made more clear that we need to re-evaluate if enabling this option
by default is a good idea.
Useful action, especially for heavy kwin rules users
As an example, this can help users to migrate their rules to Wayland
(where some matching properties such as window class may be different)
while keeping a version of the rule compatible with X11.
BUG: 429588
FIXED-IN: 5.21
On X11, it creates a dead pixel on the left edge which interferes with
left panels, the left-nost widget on bottom and top panels, and scroll
events on the left-most pixel in various apps.
It works properly on Wayland, but unfortunately turning it off by
default only on X11 but not Wayland is not easily doable. So let's turn
it off by default everywhere.
BUG: 387775
FIXED-IN: 5.21
Various fixes:
- Remove unneeded PlasmaCore import
- Re-arrange imports to be alphabetical and grouped consistently
- Use standard import names
- Use Kirigami units explicitly
- Remove unused ids
- Remove unneeded cases of setting aproperty to its default value
- Use Layouts where appropriate instead of lots of anchors
- Reduce number of unnecessary items
- Fix inappropriate mutation of `width` and `height` inside layouts
Visual changes are extremely minor and of a bugfixy nature.
BUG: 428883
FIXED-IN: 5.21
Correctly update the thumbnails' border sizes when the theme
changes and `Theme's Default` is selected,
as different themes may have different border defaults.
Before 9cf52340e, this was implicitly done on QML side.
Do it explicitly now on C++ side.
Use a single combobox instead of checkbox + combobox.
Adds a new property that acts as a proxy for the configuration value,
while internal configuration properties are kept unchanged.
BUG: 426157
BUG: 417430
FIXED-IN: 5.21
Slight UX and code improvents:
- Disable the detection button when property sheet is open.
- Add a minimum limit (smallDuration) to the delay before detecting
a window. Otherwise we freeze the window before even showing the
button release feedback, which can feel unexpected
- Prefer Q_INVOKABLE over public slot to expose method to QML
Qt 5.15 introduced new syntax for defining Connections. Fix warnings like this one:
QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
For builtin effects the information comes from the EffectData struct.
For plugin effects the X-KDE-ConfigModule key is read from the plugin metadata.
For plugins that do not yet make use of it we fall back to the old way.
For scripted effects this is empty since the config is loaded in a different way.
By default, the rules list moves to the hightlighted item
(the one being edited) with a constant velocity. This can
be too slow when the list contains hundreds of items.
By setting `highlightMoveDuration` we set a maximum limit
for this animation.
BUG: 428139
This is unnecesary and also causes a bug, overwriting
previously set properties with the new detected values
when calling for the menu `Edit window properties`.
Only set the model value when the user explicitly interacts
with the control.
This fixes a bug where some detected properties (position
and size) were not fully applied due to the the binding loop.
That commit broke CI's build, while it's building fine locally.
Let's revert it until having a better understanding of the cause.
Also revert the attempt to fix it, which didn't succeed.
This reverts commit 9cbac6fe3a.
This reverts commit 3e15f64055.
Include header "rulebookdata.h" instead of class forwarding.
The header is automatically generated by kcmutils_generate_module_data
and includes a namespace
Only a subset of KDE applications (part of KXMLGUI ones) support
this setting, and on the other hand non KDE applications
may support it as well.
As there is no way to identify the subset of affected applications
not even with technical terms, make the description a bit more
generic, leaving it open to future improvements to the set of
supported applications.
Change the labels to singular `Property` and close the property sheet
after clicking on one item.
The behaviour of the sheet is now more similar to a menu, and not so
much as a dialog which needs to be dismissed to go on.
The idea is to simplify the rule editor workflow and make it more evident
to the users. By making the `Add property` close after each selection,
the user can see immediately that the property has been added to the
rule list so they can edit it.
Also use ListView transitions to add visual hints when adding
or removing properties, and try to position the new added item
into the visible view.
Custom code for isDefault is not needed. Indeed, testing dropdown value is not needed to know if we have a default value or not. Testing theme and border size auto is enough, and it's done automatically by KConfigXT
