when creating or deleting a user is not enough to pop the old page,
but a new user needs to be selected (either the newly created one or the
one just on top of the deleted one) so that the kcm doesn't stay
half empty with an ui that looks broken
BUG:450182
On multiscreen (seems to happen only on X11 so far) when screen are
added and moved, sometimes the panel gets moved by the window manager
ending up out of screen boundaries, leaving a screen without panel
a common scenario is:
laptop with external screen connected, panel on internal screen,
close the lid, everything gets moved to the external screen,
the panel will stay out of screen boundaries, but the panel struts are correct
CCBUG:438114
With the keyboard navigation patch there is the issue that sometimes,
due to sorting by SortFilterModel, the stack order of the items doesn't
correspond to the visual order of the items.
This is a problem wrt the recently introduced keyboard navigation, as
the tab order of items in qml is completely tied to the stack order,
resulting in an erratic tab navigation order (usually happens with
device notifier or bluetooth applets for instance)
Get rid of the delayed optimal size calculation caused by Qt.callLater
and calculate optimal size immediately when an applet's size changes.
This removes the unnecessary jumping of applets that are centered between 2
spacers.
BUG: 431668
FIXED-IN: 5.24.2
Since the DesktopView has "transparent" clear color, it will allocate a
buffer with an alpha channel and QtWayland won't be able to set an
opaque region. This change sets the clear color of DesktopView to "black"
so overdraw can be fixed in kwin and to improve render performance on
wayland.
Kernel developers have said that charge limits are approximate, not
exact[1]. As a result, if for example you have a charge limit of 80%,
your battery might actually stop charging anywhere between 78-82%. But
if we only list the charge limit itself, it looks to users like a KDE
bug when the battery stops charging at any number other than that limit.
To alleviate that, this commit adjusts the text to indicate that the
charge limit is appropximate.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=215531#c3
Right now we change the intensity of shadows based on the color scheme's
text color, but with a property called "lightBackground". This indicates
that we wanted to do it based on the background color itself, but did
not or could not, so settled on using the text color as a proxy. However
this is wrong; there is no relationship between the active color
scheme's text color and the color of the background image.
Even if we could or did fix that, it would probably still be wrong,
because using lighter shadows on a genuinely light background would
result in worse contrast and readability, especially if the light
background was very visually busy.
For these reasons, in most other places, we have since settled on the
mantra of "shadows should be black", and this commit makes the lock and
login screens follow that convention as well.
BUG: 449985
FIXED-IN: 5.24.2
I cross-compiling for the recently released Arm Morello boards and the
QtQml debugger is not yet compatible with CHERI-enabled architectures so
I had to build QtQml with -no-qml-debug.
Creating and deleting users needs that too
This also means that we need to be more correct with the types passed into the DBus calls since with passing the args as list we don't get implicit conversion to the correct type any more
BUG: 450122
FIXED-IN: 5.24.2
This commit gives the accent-overridden pieces of the color scheme overridden
foregrounds as well, preventing readability issues with accents and certain color
schemes when paired up. Additionally, this MR will also prevent readability issues
with lighter colors as the text color is determined between being black or white
by the color's luminosity, aka brightness.
In addition, color schemes can be marked as applying the accent color to active
and/or inactive titlebars. This is exposed to theme creators and can be changed by
users as well.
When we are using a charge threshold, the kernel may stop charging
within a percentage point of the actual threshold and this is
considered correct behavior, so we have to handle that. See
https://bugzilla.kernel.org/show_bug.cgi?id=215531.
Also, Upower may give us a status of "Not charging" rather than
"Fully charged", so we need to account for that as well. See
https://gitlab.freedesktop.org/upower/upower/-/issues/142.
BUG: 435931
StatusNotifierItem.qml does not explicitly handle the case of
right-clicking, which causes right-clicks to be ignored unless you also
happen to have the libappindicator package installed, which injects a
handler for this itself. But this should work even if you don't have
that package installed; this commit fixes it.
BUG: 449870
FIXED-IN: 5.24.1
Sad that we still need to do this because the patch to fix that bug
never got merged because it failed to adjust a failing test, and has
bitrotted in the two years since then.
BUG: 448387
FIXED-IN: 5.24.1
OpenUrlJob
We are starting a KService, but with extra steps. Use the appropriate
job.
This fixes launching apps since OpenUrlJob, by default, doesn't launch
executables
BUG: 449900
Marco Martin
David Redondo
Martin Seher
Aleix Pol
Fushan Wen
l10n daemon script
Vlad Zahorodnii
Weng Xuetian
Ahmad Samir
Eugene Popov
Laurent Montel
Nate Graham
Alexander Lohnau
Alex Richardson
Nicolas Fella
Dominic Hayes
David Edmundson
Claudio Holo
Oleg Solovyov
Yari Polla
Waqar Ahmed