They both say the same thing, but the "broken battery" message is more
descriptive and actionable, so we can show only that.
BUG: 442906
FIXED-IN: 5.24
As it was so far, it looked like the system was malfunctioning because
we were showing a battery with a big fat red mark. If there's no battery
we can show the default icon.
As for the name, we only say "battery and brightness" when there's
both of them. Otherwise we show either title.
If neither batteries nor brightness are available, we mark the applet as
passive so people can at least still access the power management blocking
checkbox which lives here.
BUG: 415073
FIXED-IN: 5.24
The triangle mouse blocks events that happen within a given region and
conditions, then replays those events when those conditions get broken.
If we intercept an enter event, we capture that under
m_interceptedHoverItem so that if conditions change we can replay that
hover enter event before we then start sending move events.
Currently we replay that hover event using the current mouse position.
This causes an issue for kickoff that has additional code to look for
actual move events in order to avoid selecting the current item on
scroll. Both codepaths are correct standalone, but together form a bug.
This patch caches the relative position of a HoverEnter event. Should we
replay the enter event, we do so with the position of the enter. We then
can replay a HoverMove to get the up-to-date location.
BUG: 447278
Adds `visible` binding to the whole layout with(out) inhibition hints.
It makes the component as a whole disappear from its parent layout, so
even though its height is zero (no visible children), it would still
count toward spacing calculations, which doesn't make sense.
Decouple inhibitions list view (Repeater) from the label above.
TODO: worth refactoring into a view with header, and settings their
visibility on a higher level?
GIT_SILENT
Makes it consistent with most other inhibition hints in this layout.
If we are not displaying info about about inhibitions when only one is
active, then why would do the opposite when more than one is there?
The plan is to eventually transition it to some sort of reactive model,
e.g. ListModel or C++ based one. Meanwhile, a simple js array of
objects is fine too, but is should be explicit and documented.
The system tray doesn't follow the panel opacity (it's always
transparent even when the setting is set to opaque or dynamic
with a maximised window present)
BUG: 439025
FIXED-IN: 5.23.5
Fixes the following error:
/usr/share/plasma/plasmoids/org.kde.plasma.battery/contents/ui/CompactRepresentation.qml:74:
ReferenceError: batteryLabel is not defined
batteryLabel does not exist ever since commit
27ac0b7608 back in 2016, so an attempt to
calculate some icon's height based on its size was bound to fail.
Currently this is hardcoded to KOrganizer, but Kalendar is a nice app and we should be able to launch that too.
Check for the default handler for calendar files and take that if it is KOrganizer or Kalendar. The check is to avoid launching an app that can technically open ics files but isn't a calendar app, e.g. Kate.
We can extend the logic with other known calendar apps
The scale factor was incorrect because it always compared with 1, which
caused the background image not being resized properly when height >
width.
This commit uses the same scale factor in ToolTipInstance.qml, so the
scale factor is correct again.
There are many languages (including Russian) where three three power
profile titles do take much more space than it is available in applet.
RowLayout's spacing ensures they do not stick to each other side by
side.
Ideally, we should have "shrinking labels" which are capable of
adjusting their text's kerning based on available space. In the
meantime, localization teams are advised to use as short profile names
as possible without loosing their meaning.
Layout code should avoid implicit/preferred size from being influenced
by explicit/resulting size, as it opens possibilities for binding loops
and other errors.
GIT_SILENT
QtQuick.Layouts are easier to manage, and more flexible.
In case of fillWidth+preferredWidth, preferredWidth defines a ratio
rather than an absolute value, so it was replaced with a singleton `1`
instead of a magic number `50`. Since size of this applet propagates
top-down only, it should not affect any calculations, especially
because `50` is too narrow to fit any reasonable text label, except
maybe Chinese.
Rename ids to make them easier to read. They are intentionally named
differently from their aliases to reduce potential confusion, e.g.
* icon -> image
* slider -> control