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
For the following KCM :
* KWin Options
* KWin Screen Edges
* KWin Tabbox
KCModule introduce an indicator to show which settings have changed from
default value. Unfortunately some KCM have settings' states which are not managed
automatically by the KCModule thus we have to handle it manually.
see https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/9
This change replaces the remaining usages of the old connect syntax with
the new connect syntax.
Unfortunately, there are still places where we have to use SIGNAL() and
SLOT() macros, for example the stuff that deals with d-bus business.
Clazy was used to create this change. There were a few cases that needed
manual intervention, the majority of those cases were about resolving
ambiguity caused by overloaded signals.
This adds a setting to the window options KCM to disable KDE apps
remembering their own window positions on X11, and instead always use
the KWin placement modes.
The setting sets an option in `kdeglobals`, rather than kwinrc, as it is not
a KWin-specific option *per se*. The UI is also hidden on Wayland, as it it
not relevant there because the functionality it disables does not work on
Wayland. Instead, remembering window positions will eventually be implemented
in a different way and affect all windows, not just KDE windows.
See https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/14 for
more details.
CCBUG: 415150
