The QStringView::to<Number>() methods in Qt5 cause one extra allocation
compared to the QStringRef counter-part. As long as we aren't on a hot
path this is probably not worth the extra #ifdef though.
Instead of relying on the thumbnail strip size, which can temporarily
change during (re)layouting and/or be incorrect when we initially fetch
the thumbnail.
The potential change in image fidelity in notification history is
imho justifiable over the improved speed and reliability of thumbnail
generation when we don't needlessly create a pixmap we don't use.
BUG: 401579
FIXED-IN: 5.25
Best used in conjunction with with
https://invent.kde.org/frameworks/kio/-/merge_requests/780 which will
allow kicker recentUsageModel not to make any stat call but solely
base its iconName based on passed mimetype, allowing to act as if
KFileItem::SkipMimeTypeFromContent was set.
Especially for longer downloads where a user is more likely to minimize
the job popup, it is useful to be able to see basic job information
(title, i.e. "Downloads", percentage) without having to open the
notification history.
Moreover, it can be hard to judge completion percentage from the tiny circle.
Rather than relying on `Plasmoid` from deep down in `NotificationItem` code,
which is not possible when run inside the popup.
In `Globals` we have access to our own `plasmoid` property directly.
`Globals` (popup handling) is a singleton and as such has no access
to context properties like `plasmoid`. To remain "API-compatible"
there is a `plasmoid` property in `Globals.qml`.
However, this broke with the port to a singleton type and is
admittedly bad layering.
Move drag handling into a proper singleton type to avoid
cross-referencing `plasmoid` from ten layers deep down the code.
Qt6 insists on that. We can do this either by including the moc files,
or by including the corresponding headers in the header defining the
properties, the former seems cleaner.
That's in a plugin we don't link against here, we only see its header.
This happens to work with Qt5, but Qt6 wants fully defined types for
properties. Use a QAbstractItemModel pointer instead, we only access that
API anyway, and for QML the difference doesn't matter.
Discover current minimum height of applet labels in hidden
view and apply it for all of them when they are shown
inside hidden applets view. This implementation provides
always only the maximum needed label height based on label
contents.
BUG: 438347
FIXED-IN: 5.24.3
The prefered is to show context menu on mouse pressed event, not click,
but this causes few issues for SNI.
Some legacy applications still relies on XEmbed to show tray icon.
We use xembedsniproxy to relay the mouse press signals to the XEmbed client
but some applications (including GTK) validate the mouse state.
Mouse released state is expected, but as it is still pressed context
menu does not show.
BUG: 409768
FIXED-IN: 5.24.3
Unlike when the clock is in a panel, there is plenty of space when it is
on the desktop. This means that we can safely let the date string word
wrap rather than shrink.
BUG: 450632
FIXED-IN: 5.24.3
1. Don't change the current item when not saving it.
2. Use Qt.callLater as the item will be moved to the top after saving
it, and we would like to hightlight the real first item.
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
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
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