https://bugs.kde.org/show_bug.cgi?id=491181
Bug ID: 491181
Summary: Notifications stack instead of auto-dismissing /
collapsing
Classification: Plasma
Product: plasmashell
Version: 6.1.3
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Notifications
Assignee: plasma-b...@kde.org
Reporter: vlov...@gmail.com
CC: k...@privat.broulik.de
Target Milestone: 1.0
SUMMARY
Every morning at 4AM I have my router set to reset. If I don't use my computer
for a few days, there's a giant stack of sizable notifications that say
"Connection 'Ethernet' deactivated" from Network Management. Ideally, such
notifications should be dismissed the moment the Ethernet connection comes
back; the appropriate place to notice that it's disconnecting every morning at
4AM is in logs if I care, not in the UI.
This isn't just a Network Management problem. I see the same thing from battery
notifications that my wireless mouse and keyboard have low battery. That
notification pops up when I start using the mouse even though I have weeks of
battery life left and it stacks instead of replacing the previous low battery
notifications. Similarly, if I replace the battery all the low battery
notifications remain instead of being dismissed.
Another example is Signal - I receive an incoming voice call and the
notification is still there even though I answered the call on another device.
And the notification is clearly stale because it says "Incoming voice call"
instead of something useful like "missed call" if I did happen to miss it
rather than answer it on another surface.
No other platform is perfect, but none of them have quite this annoying level
of behavior and I regularly use MacOS. The Signal example might be able to be
blamed as the 3p developer not doing something correctly, but given this
impacts applications within the KDE ecosystem, either the APIs to do the right
thing don't exist or they're too cumbersome to use correctly.
OBSERVED RESULT
Notifications about the same event stack instead of simply removing previous
instances of the same notification before adding the new one. Similarly, when
the state backing the notification is no longer relevant, the notification
sticks around. This requires too much manual interaction with the notification
system to dismiss events just so that they don't clog up the screen.
EXPECTED RESULT
Notifications about some transient state should be automatically dismissed once
we leave the state (e.g. connection reactivating, batteries replaced, or
incoming call answered somewhere else).
Notifications about about a state that's already been notified about should
cause the previous notification to be removed (e.g. if I ignore the low battery
notification, it shouldn't keep adding to the notification stack just because I
moved the mouse & it noticed the battery state & prompted a notification).
SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.8.4-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 32 × 13th Gen Intel® Core™ i9-13900KF
Memory: 62.6 GiB of RAM
Graphics Processor: llvmpipe
--
You are receiving this mail because:
You are watching all bug changes.
