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.
In most cases the port is trivial and can even simplify the code like in
the case of the system tray applet. In the case of notifications applet,
this is causing a bigger refactor and it's now also using a TextArea
that provides the automatic scrolling when selecting behavior.
CCBUG: 437155
Sets the profiles via the wrapped ui in powerdevil if available.
If the performance profile is inhibited, the second half of the slider
will look disabled and it will be impossible to move it to performance.
Co-authored-by: Kai Uwe Broulik <kde@privat.broulik.de>
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
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`
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>) { ... }
At the moment, in the battery widget, the slider displays the brightness of the screen, but
it doesn't have text labels, so it's quite difficult to determine the brightness of the
screen. Adding a label over the slider that will display the current screen brightness as a
percentage will make this applet more descriptive and handy.
Summary:
This patch implements part of the mockup at T10470 by putting the power management
checkbox and settings button in a heading area visually connected to the titlebar.
In the process, I fixed a problem with the power management checkbox to make the layout's
spacing work: the checkbox now has text of its own, instead of living in a mouse area
with a separate label.
Test Plan:
{F8254807}
{F8254808}
Reviewers: #vdg, #plasma, broulik, niccolove, manueljlin
Reviewed By: #vdg, manueljlin
Subscribers: plasma-devel
Tags: #plasma
Maniphest Tasks: T10470
Differential Revision: https://phabricator.kde.org/D29116
Summary: With other two patches, this aims to make leftMargin consistent in widgets (See https://phabricator.kde.org/D26945 and https://phabricator.kde.org/D26944)
Test Plan:
System tray
Before:
{F7977382}
After:
{F7977379}
Notifications
Before:
{F7977359}
After:
{F7977357}
Battery monitor
Before:
{F7977362}
After:
{F7977361}
Self reminder: networkmanager is still slightly badly aligned
Reviewers: #vdg, #plasma, ngraham
Reviewed By: #vdg, ngraham
Subscribers: gvgeo, ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26946
Summary:
Use QQC2.Slider, so that we have a moved signal. This way we can only
issue new brightnesses when the user actually interacts with it.
Don't adapt to the system brightness until we have finished interacting
with it.
Test Plan:
Manual testing, flickering is very much reduced both when scrolling over the
compact plasmoid as well as the slider.
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D26035
Summary:
BUG: 345940
Move the "Enable Power Management" checkbox to the top of the window to match other applets (bluetooth, network)
Reviewers: #plasma_workspaces, broulik, mck182, davidedmundson, mart
Reviewed By: #plasma_workspaces, davidedmundson, mart
Subscribers: mart, jensreuterberg, davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8607
Calculate the plasmoid status and tooltips in a binding rather than invoking
Logic.updateFoo manually; this way we can have the QML engine do what it can do best.
Unfortunately it cannot look inside JS objects, so we cannot have the inhibitions
be handled the same way.
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.
Prevent a "You don't say" moment, only show the OSD when using the mousewheel on the tray icon
to provide feedback. Also make it more finegrained and allow 5% steps on the tray icon
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
This finally allows us to have predictable sliders where a wheel whill always
result in a brightness change rather than having it go from 0 to 10 which is still
below 33% in case of 3 keyboard brightness steps resulting in no change whatsoever.
It also shows 0/3, 1/3, etc instead of percentage in such cases.
Also clean up a bit, remove superfluous clipping and prevent brightness change
on popup instantiation
Makes it look better (no empty gap) and given you can change brightness using keyboard
shortcuts and mouse wheel, the looks outweigh the additional mouse travel
BUG: 336708
FIXED-IN: 5.1
I am really tired of this topic. Yes, the battery remaining time is not that accurate and
jumps around (the latter is something that could be fixed using a moving average). But if
we jump onto that train we would also need to remove the battery percentage itself as it's not
accurate either. 30% on a dead battery can quickly become 5% and then the notebook suddenly
turns off. "Battery: Present".
The remaining time is in the battery's tooltip, many distributions have even patched the
battery monitor to show the time by default, there's even a clone of the original battery
monitor on GHNS just with that option enabled; every other desktop environment even emphasizes
the remaining time, Windows prefers the time over percentage, Mac OS X allows you to put
the remaining time in the panel rather than the percentage, etc etc.
As a maintainer I now made the decision to show remaining time by default - it's no
"in your face" display but in the battery's detail section - and I would kindly
ask all the people involved in this discussion to respect this. Thank you!
BUG: 290578
- Batteries are now in a proper ScrollView since in Plasma 5 popups can not (yet?) be resized
- Get rid of that expanding thing for details, it was fancy and all in 4 but doesn't play well with 5
- Use ToolTip for battery details
- Remove redundant information (non-power supply display name is always vendor + model, no need to show these in the details again)
- Make icons medium size to be consistent with Plasma NM
- More refined spacing
This patch simplifies the battery's ui, and brings spacing in line with
Plasma 5 standards.
In detail:
- removing the selection item on batteries: it's already visible by the
text shown that the battery is selected. It also doesn't need the
selection semantics across the ui, because -- for what?
- remove separator lines, in Plasma 5, we use spacing for this case
- Improve HighDPI by removign hard-coded layout hints, use units.gridUnit
throughout
- Fix batteryitem's status: it would show the wrong icon and time label,
because AC Adapter can be empty. Checking charging is semantically
correct here, since it uses the charge state, not the adapter state.
- remove a bunch of SVGs that were used internally to get margins -- use
gridUnit for layout internal margins instead
- fix slider's right alignment, this would jump based on the percentage
label's width, which varies per item. We know the rough length of the
percentage label from the context, and can align the labels to that.
Thanks everybody for the reviews!
REVIEW:118272
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://community.kde.org/Frameworks/GitOldHistory
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo kde-workspace, frameworks branch, at commit
049113e719dd2fc4446d054fa1a3aada330094f0