When an applet is about to be deleted, it will save its config
automatically, but in this case the system tray doesn't need to load the
config again.
BUG: 453726
(cherry picked from commit 6da91d053b)
In case both IconName and IconPixmap are provided, the system tray
applet is going to prefer the pixmap.
That can create a dark icon on dark background bug because plasma can't
recolor pixmaps.
The SNI spec recommends visualizations to prefer icons over pixmaps:
> An icon can either be identified by its Freedesktop-compliant icon
> name, carried by this property of by the icon data itself, carried by
> the property IconPixmap. Visualizations are encouraged to prefer icon
> names over icon pixmaps if both are available (FIXME: still not very
> defined: could e the pixmap used as fallback if an icon name is not found?)
BUG: 418996
(cherry picked from commit 7363d0e0f3)
When a service appears right after the ListNames() call finished, but
before the QDBusPendingCallWatcher is set up, the ::serviceRegistered
signal will be queued before the ListNames() response. As a result,
the service will be ignored by DBusServiceObserver.
Switching to QDBusInterface::callWithCallback() ensures that the
result slot is queued as soon as the response arrives, thus avoiding
the race.
Credits go to Sam Edwards for identifying the problem in
https://bugs.kde.org/show_bug.cgi?id=422111#c69
BUG: 422111
(cherry picked from commit 3751f49cc5be219e63c7fae1df9f1b6e77f5762a)
If preferred, compact and full represenation are set to the same value,
the value of appletShouldBeExpanded will be true, which means the applet
will be expanded by default. In this case, only fullRepresentation will
be created and compactRepresentationItem will simply be null.
If compactRepresentationItem is null, also check the fullRepresentation
for mouse event forwarding.
This fixes manage-inputmethod applet not working if it's hidden in the
tray.
(cherry picked from commit 69702475e5)
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
(cherry picked from commit 8fcdfc309f)
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
(cherry picked from commit a02d1ca27b)
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
(cherry picked from commit 03f982261b)
All the sizing and positioning code in this SvgItem relies on assumption
that plasmoid's location would we strictly either one of four edge
types. So this patch ensures that this thin separator line is only
visible when this assumption is true. Otherwise its both width and
height get reset (by binding `undefined`), and SVG starts filling up
the whole available area, which leads to a visual glitch that looks
like a as grayed out or faded applet.
See also: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/576
BUG: 449535
(cherry picked from commit eb2fe69302)
The MouseArea in AbstractItem needs to be above applets
when it's in the grid hidden area so that it can receive
hover events while the mouse is over an applet
But when the applet is shown as an icon on the regular
systray it needs to be below so the PlasmoidItem `onClick`
takes precedence and systray collapsing works.
BUG: 449533
FIXED-IN: 5.24
(cherry picked from commit a321bbcefe)
Applets in PlasmoidItem were blocking events from reaching the
ToolTipArea, so I moved the on hover logic to the AbstractItem's
MouseArea and put the MouseArea over the iconContainer. The
iconContainer is the parent of applets. Presses tend to hit the center,
which is where the applet is, preventing ToolTipArea::containsMouse from
being true and preventing the highlight from moving to the pressed item.
Hopefully this doesn't cause duplicate actions when events reach the
applet. I tested the patch on the nightcolor applet and all the other
default applets and didn't see anything wrong. I think this may be
because the signals are sending QML MouseEvents to the applets, causing
them to be accepted if the applet can accept them. Then when the signal
handlers are done, since the events are already accepted, they should
not move beyond the MouseArea and cause another round of event handling.
(cherry picked from commit d58b9eabf3)
PlasmoidPopupsContainer.qml has special code to handle merging headers
from applets if those applets use a PlasmaComponents3.Page instance as
their FullRepresentation. However this breaks for any applets that use
PlasmaExtras.Representation, which is a subclass of it that we have been
porting applets to over time, because it offers more features in a
single location. This caused the detection to break, so such applets
woudl have their headers improperly merged.
Explicitly detecting the use of PlasmaExtras.Representation as well
fixes it.
BUG: 438178
FIXED-IN: 5.24
(cherry picked from commit 7221ffd1a9)
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 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