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
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
Pass remainingTime property explicitly instead of looking up the
top-most item via implicit scoping / context. It doesn't work well
especially in ListView delegates. Besides, there already was such
property in the PopupDialog, although it was unused until now.
Amends 7d0f1a014c, this time for real
Moved aforementioned component's source code directly to the only place
of its instantiation left.
Boolean property `inListView` which was responsible exclusively for the
font size selection, got totally abolished and replaced with font
bindings themselves.
Other boolean properties of the grid were marked as `readonly` which
they should've been from the beginning; and {Left,Right}Labels' binding
to them had to be qualified with property access by id, which --
again -- was just an oversight, and worked only because it was a
top-level(even though an 'inline') component.
Renamed GridLayout's `id` to simply "details" for better readability.
It remained always hidden ever since
df2469e7d2, and there were no plans to
revive it anyway. I did some cleanup and layout refactoring before
dropping it though, just in case, so this removed code pretty much
worked and looked good.
It was necessary to drop the `required` qualifier from inListView
property due to a bug in Qt/QML compiler which somehow considers
`required` properties of inline components for named roles resolution,
but only when they are also directly instantiated somewhere in the file
as opposed to deferred instantiation via `Loader::sourceComponent`.
ToolTipArea::active is now bound to just false, which was the case ever
since df2469e7d2. It's going to be removed
completely soon.
The code is not consistent on how do we access properties (role names)
of rows/models of Plasma Data Engine's Data Source. This is obviously
due to the fact that some properties (role names) contain literal
spaces, and thus -- as explained in previous commit -- are currently
inexpressible in terms of QML properties.
However, even at the cost of inconsistency, `battery.State` reads better
than `battery["State"]`; while `battery["Is Power Supply"]` reads the
way it is, just because there's literally no other way around it.
(Actually, we could create a ECMAScript class, and deserialize data
source's row into sanely named fields. But that's a good proposal for
another patch.)
Top level item's `property var battery` is unambiguously set to the
`model` value itself in the ListView's delegate declaration in
PopupDialog.qml component. The fact that there were used two equivalent
methods is strange, but likely happened due to an incomplete
refactoring some time in past.
The intention is to make it as short as meaningfully possible, as it is
used a lot in expressions, and will be used even more after porting the
rest of accesses to the dynamically scoped `model` variable to the
equivalent `root.battery` property lookup.
They were supposed to be in the column on the right this whole time, as
was indicated by an artificial Layout.leftMargin (ex-anchors.leftMargin).
Cons: Now the ToolTip pops up anywhere over a possibly lengthy details
and inhibition hint's text.
Pros: The ToolTip is never active.
This is a direct translation of anchors to QtQuick.Layouts, except
gridUnit in leftMargin is replaced with something it was really meant
to be: the value of a margin on the right side of the batteryIcon,
which happens to be the RowLayout's spacing.
But once we yeet the ToolTipArea (or even before that), those
BatteryDetails and InhibitionHint components should be placed inside
the infoRow's ColumnLayout.
Replaces Row/Column with RowLayout/ColumnLayout, and x/y/width/height
with appropriate Layout.margins and preferrewWidth bindings.
Layout.* properties of the mainItem itself are now greatly simplified,
because top-level RowLayout manages its implicit width just fine.
Maximum width for BatteryDetails component is back, after it was lost
in 44ed25e521 refactoring.
GridLayout no longer crashes was described in an old comment and
nowadays is pretty safe to use. Repeater, however, still doesn't
support instantiating multiple top-level items at once, which is
unfortunate but can be worked around; see upstream Qt bug below.
In this case, however, simple is better than smart-ish; the entire
at-most-two-rows table-like grid can be recreated entirely without
Repeaters and clever models. Just do it.
See also: QTBUG-38098
However weird that title might sound, a lowercase `component A : B`
syntax allows us internalize any property, and even make it required
for an instantiator to provide. This no longer relies on implicit
scoping of QML.
GIT_SILENT
This is still borken as hell, because x/y were not supposed to work
inside Row/Column anyway.
PlasmaCore.Units.largeSpacing is inconsistent with Kirigami, and
actually equals to gridUnit, and 4 times as big as smallSpacing. So,
the proper replacement for a `largeSpacing / 2` (which also properly
takes care of rounding to an integer) is `smallSpacing * 2`. And the
largeSpacing itself shall be replaced with gridUnit to avoid confusion.
GIT_SILENT
Optimize previous patch that introduced extra margins for the battery's
progress bar in order to make its labels visually match the distance of
brightness sliders on top of it.
This patch moves `referenceSlider` property to the root component of
BatteryItem.qml, so that an existing item can be passed from the
outside. It keeps the default value there just in case, but it won't be
instantiated by QML engine when the property is overriden at component
declaration. (Note: this won't be true if the slider had an id set.)
Since we are defining some properties on the top-level component, we
might as well move the `extraMargin` here, so that the actual
ProgressBar component now won't have any properties on its own, and
thus QML engine won't create an extra runtime QML type just for it.
Add vertical margins to the battery progress bar, so that the distance
between colored bar and labels on top of it is the same as for the
sliders. This patch bases on assumption that sliders are always thicker
than progress bars, but guards against surprises by clamping from 0.
This also means that custom spacing of the parent ColumnLayout is no
longer needed, as it has only two children, and the equivalent Column
in BrightnessItem also has spacing set to zero.
This is done because QtQuick.Layout types are more convenient to work
with, and to avoid `with: parent.width` kind of boilerplate.
Nested RowLayout does not need Layout.fillWidth property, as that is the
default behavior for nested layout types.
GIT_SILENT
The power management inhibition UI is currently somewhat confusing to
users because it's not clear that the checkbox is a local override for
the permanent settings set elsewhere in System Settings.
A good sign that the UI is sub-optimal is that we refer to it as "power
management inhibition" internally and in our developer conversations,
but the UI expresses the opposite: *allowing* power management, not
inhibiting it. This conflicts in the user's mind with the UI in System
Settings that is also expressed in terms of allowing it. It is further
confused by the fact that the message about apps suppressing power
management is phrased in terms of being an temporary override, and that
we also show an unrelated message about the battery charge limit (if set)
in the same place where we're notifying the user about power management
inhibition.
Let's clarify this UI by doing the following:
- Re-word the checkbox's label to emphasize that it's a local override
for the settings that were set elsewhere
- Move the charge level message into the battery item itself, since
that's what it affects
- Slightly re-word the message for when apps are inhibiting power
management to emphasize that power management can be inhibited
automatically by apps in additionto manually by the user
BUG: 435827
FIXED-IN: 5.22
We ported units to use the PlasmaCore.Units singleton earlier; now it's
time to do the same thing for PlasmaCore.Theme.
There are no UI changes or regressions detected.
The context property version is slower to access and won't be supported
in Qt6. Let's port away from it and use the singleton version instead.
Here was my full process for making this change:
1. Made the change with `find . -name '*.qml' | xargs perl -pi -e 's/units\./PlasmaCore\.Units\./g'`
2. Verified no more occurrences with `grep -r " units."`
3. Made sure this didn't change any comments in a silly way by inspecting the output of `git diff | grep "+ " | grep "//"`
4. Manually inspected the full git diff to make sure there were no other unintentional or silly changes (there were none)
5. verified that all changed files have the PlasmaCore import with the correct name with `for FILE in `git status | grep modified | cut -d ":" -f 3`; do grep -q "as PlasmaCore" $FILE || echo "$FILE needs the PlasmaCore import"; done`
Summary:
Otherwise we're discarding style information possibly set in
the user's small font choices when we want to set a smaller
font.
Test Plan: Stuff that's suposta look small still looks small
Reviewers: cblack, #plasma
Reviewed By: cblack, #plasma
Subscribers: ahiemstra, apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D29437
Summary:
After the change to "Capacity degradation" was announced on
https://pointieststick.com/2019/08/24/kde-usability-productivity-week-85/, it turned out
that nobody could understand the new string either. :(
This patch changes it to something much clearer: suggested by a user: "Battery health".
This string has the advantage that it does not require knowing that batteries degrade,
and uses the same percentage scale as other operating systems.
Test Plan: {F7279584, size=full}
Reviewers: #vdg, #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, aspotashev, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23448
Summary:
Companion patch to D23270
The same logic explained in D23270 applies here: using the text "Capacity degradation"
is much clearer than "capacity" when referring to how much of the battery's original
capacity is remaining due to degradation.
Test Plan: {F7264994, size=full}
Reviewers: #vdg, broulik, #plasma, filipf
Reviewed By: #vdg, broulik, #plasma, filipf
Subscribers: aspotashev, filipf, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23271
Summary:
Retry after D23237
Vendor and Product will be shown in the energy information kcm after D23152
Test Plan:
After:
{F7260208}
Reviewers: #vdg, #plasma, broulik, ngraham
Reviewed By: #vdg, #plasma, broulik, ngraham
Subscribers: ngraham, alexde, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D23260
Use Layouts where applicable and clean up a bit. Makes the code much easier to follow.
Also drop meaningless percentage for brightness as suggested by the usability team.
Implicit/paintedHeight causes binding loops when eliding is enabled, also when Repeater
recreates items they don't immediately have a parent (for whatever reason) also throwing warnings
BUG: 343047
FIXED-IN: 5.2.1
Needs further investigation on why it crashes but probably when the Repeater recreates
the items due to data changing somewhere.
Also use modelData to access model data.
Reviewed-by: Lukas Tinkl
Tooltips aren't particularly discoverable. This also refactors the code away from using
a string containing a HTML table (which doesn't play well with RTL languages) to a fancy
Array and a GridLayout that is shared between the battery tooltip and the main view
BUG: 337996
FIXED-IN 5.2.0