I know we can't have interactive expired notifications (Bug 407361). However, we do store information about which app sent each notification, so we could at least make expired notifications in the history launch or focus the sending app when clicked. This would really help the typical notification workflow where you go to the history to see what you missed, then go to the app that sent each one to see everything or complete an action.
*** Bug 416644 has been marked as a duplicate of this bug. ***
An "app" can have many open instances or associated windows (such as when one composes an email). Unless this specific information is stored, it could be a mess to randomly focus one of many open instances or one of many associated windows.
What we can do is activate the default action when clicking on the history item, just like with the popup. That however only works if 1) there is a default action set by the app 2) the app passes the "resident" hint
*** Bug 447389 has been marked as a duplicate of this bug. ***
Sounds good to me. Though I wonder what the point is of making the app pass the resident hint? Wouldn't we want this for everything, unconditionally?
Without the resident hint the app throws away its internal notification object, so it could not react to the action being triggered
*throws away when the notification popup closes
Can we not vote for this?
(In reply to Aroun from comment #8) > Can[not we] vote for this? Indeed, it seems, that `plasmashell` maintainers do not allow users to upvote their bugs.
(In reply to Nicolas Fella from comment #6) > Without the resident hint the app throws away its internal notification > object, so it could not react to the action being triggered That may not be true. Applications may not set the resident hint while still specifying notification actions. The applications won't be stupid enough to throw away its internal object if it sets any action. Hence, the logic should be like if the notification has any action, keep it interactive in history.
(In reply to Puspam Adak from comment #10) > (In reply to Nicolas Fella from comment #6) > > Without the resident hint the app throws away its internal notification > > object, so it could not react to the action being triggered > > That may not be true. Applications may not set the resident hint while still > specifying notification actions. The applications won't be stupid enough to > throw away its internal object if it sets any action. > Hence, the logic should be like if the notification has any action, keep it > interactive in history. We don't need to guess/assume here, only look at what KNotifications does. KNotification objects self-delete when the notification popup is closed. Other implementations may behave differently, but we know how KNotifications behaves and have to consider that other implementations do as well
FYI: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2178 Not sure why it wasn't auto linked here