This reverts commit 354f7da871.
Somehow it prevents inhibitions from being visible in the UI. Since the
reason is not yet understood, let's revert for now to prevent releasing
a regression while we investigate.
CCMAIL: me@ratijas.tk
In the process, the onWheel handler is moved up to the main file so that
it gains write access to the screenBrightness property. This is how
other scrollable applets handle the same situation.
In the CompactRepresentation, we can use existing top-level properties
instead of defining and redefining a bunch of new properties at
various levels, which makes the code harder to read and more indirect.
In Wayland session data sources for modifier keys might be unavailable,
in which case the whole `source.data.Alt` is undefined. Standard
JavaScript try-catch didn't help much, because short-circuiting
operator && simply returns left-hand-side `undefined` value which is
falsy. It used to spam error messages to a console at a rate
proportional to the number of top-level menu items:
file:///usr/share/plasma/plasmoids/org.kde.plasma.appmenu/contents/ui/main.qml:112:17:
Unable to assign [undefined] to bool
Amends 156415f377
f9e39815dc introduced a few regressions by
blowing away the custom CompactRepresentation when there are no
batteries. This introduced a race condition that sometimes set the icon
incorrectly and also broke scrolling on the applet to change the volume.
This commit fixes those issues by using the existing infrastructure for
the CompactPepresentation, but simply swapping out its custom battery
icon for normal icon when there are no batteries.
It was nuked years ago, so the id does not exist any longer, and
generated a runtime error like this:
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/CompactRepresentation.qml:132:
ReferenceError: jobProgressItem is not defined
Amends da86d1e40a
Outside of tablet mode, you don't need a virtual keyboard except for the
extremely niche case of not having a physical keyboard plugged into a
desktop machine. For all other use cases, the tray item to show and
hide the virtual keyboard is an annoyance when you're not in tablet
mode, so let's demote it to the expanded popup to save space in the
System Tray and make its contents more contextually relevant.
Normally we don't use Kirigami in applets, so this might on its face
seem odd, but it's there for a reason, so add a comment explaining why.
GIT_SILENT
the filtermodel only sorts by timestamp of the device, not the actual
types we visualize so you can conceivably have sections appear multiple
times
```
Drives
--------
/dev/sdc
Media Player
------------
/usb/123
Drives
-------
/dev/sdd
```
a device without StorageAccess cannot be mounted, so do not show the
mount default action for it, instead use the file manager action (with
the assumption that the trigger actually knows what to do with it, which
chances are it does not because we ignore the predicate system for some
reason - I've recorded a todo about that)
when then triggering the default action we check if the device supports
MTP and if so run the MTP predicate instead of the openin predicate
the end result is that phones with only MTP actually open via mtp://
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