| Summary: | Clicking on an expired notification in the history should launch or focus the app that sent it | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Nate Graham <nate> |
| Component: | Notifications | Assignee: | Kai Uwe Broulik <kde> |
| Status: | ASSIGNED --- | ||
| Severity: | wishlist | CC: | agurenko, aneesaf1, benyamin.dudov, dag, dashonwwIII, dev.bacteriostat, kde.podagric, kde, m.j.gritli, maltejur, mata987, nicolas.fella, nortexoid, p.r.worrall, plasma-bugs, poccil14, postix, puspitaadak9876, putr4.s, xnaxdy |
| Priority: | HI | Keywords: | usability |
| Version: | 5.15.90 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=459774 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Nate Graham
2019-05-17 21:19:55 UTC
*** 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 *** Bug 489820 has been marked as a duplicate of this bug. *** *** Bug 486046 has been marked as a duplicate of this bug. *** *** Bug 493701 has been marked as a duplicate of this bug. *** |