Created attachment 119929 [details] Non-interactive notification in history SUMMARY New notification system; everything from git master STEPS TO REPRODUCE 1. Have updates available in Discover 2. Receive notification about this 3. Ignore or dismiss the notification 4. Click on notification history system tray OBSERVED RESULT The notification history entry for the update is non-interactive; if I click on it, nothing happens, and it has no "Update" button the way the actual notification bubble does EXPECTED RESULT The history entry should be interactive, so I can click on it and go to Discover to see the updated it's telling me about
Created attachment 119930 [details] Interactive notification pop-up
Actually, I just noticed that KIO's file transfer notifications retain their buttons in the history. Why can't Discover's update notification keep its "Update" button? Is this a Discover bug?
These aren't "notification actions" handled by an application but done internally by the notification plasmoid. It just remembers the URL and can then provide the "Open" button and menu.
Hmm, is there any way we can re-use that for Discover? Or would that be a mess? Alternatively could we just do Bug 407667 instead?
I'm having this issue on Manjaro 18.04. Are there any workarounds to keep notification history with a working link? Is this fixed on Neon or other releases?
In case it's helpful info: I've noticed that when you get the popup notification that is visible for 5 seconds: If I click the notification tray during that 5 seconds while it's visible, there is a button under the notification that says 'Activate'. If you click the 'Activate' button, it will take you to the correct link. If you wait for the popup to go away, the activate button will no longer be available, and you will not get a relevant link. I have also noticed a minor difference between Chromium and Firefox: When I subscribe to the push notifications in Chromium, I do get a link to the root of the website. In Firefox, there is no link at all.
*** Bug 414706 has been marked as a duplicate of this bug. ***
If this is a restriction of the spec, we should consider trying to amend the spec to accommodate it.
Is there a way to support buttons in the history for GTK apps notifications? Background: I got an invite within a chat app (Dino) which was displayed as a notification popup with two buttons: Accept and reject. However, when I waited too long the notification was gone and the history gave me no chance to react to the invite. :-/
This makes the entire "push notifications" thing browsers have nowadays pretty much useless. Why do I need web notifications when I can't click them? Is there any workaround, maybe an alternative notification history applet/plasmoid/whatever that does NOT strip the clickable links from the notifications?
*** Bug 429653 has been marked as a duplicate of this bug. ***
Any progress on this?
Git commit a01c7813b91406e4419a4eb43870b1698f7bf78e by Kai Uwe Broulik. Committed on 14/03/2021 at 19:02. Pushed by broulik into branch 'master'. [Notifier] Use resident notification This way the "Show updates" button remains usable when the notification expired. M +0 -1 libdiscover/resources/discoverabstractnotifier.notifyrc M +1 -0 notifier/DiscoverNotifier.cpp https://invent.kde.org/plasma/discover/commit/a01c7813b91406e4419a4eb43870b1698f7bf78e
We now have a generic opt-in system for this, but apps need to opt in. Discover already has. So let's mark this as fixed
*** Bug 438161 has been marked as a duplicate of this bug. ***
In https://invent.kde.org/frameworks/knotifications/-/merge_requests/35 i see the text "let's not make this public API until we know for sure this is what we want". So - is this feature safe to be implemented by 3rd party apps or not yet?
It just means there's no proper public method or flag to set it in the KNotification class. Any app can just send this hint along and will work just fine.
*** Bug 441912 has been marked as a duplicate of this bug. ***
Kai, for any notifications that are still not interactive in the history view, what needs to be done to fix that?
*** Bug 453356 has been marked as a duplicate of this bug. ***
> Kai, for any notifications that are still not interactive in the history view, what needs to be done to fix that? they need to pass the 'resident' hint
I think this issue deserves reopening, since what KDE does is different from other projects (such as GNOME). On GNOME, I can click a Telegram Desktop notification that disappeared into the notification drawer on the panel. On KDE, that does not work. On a related note, even for Discover, which keeps a button in the history, clicking the body of the notification does not work, while this does work for the active notification.
Cinnamon DE also has interactive notifications. Closing this issue means that there are no intentions to fix it.
The feature in question was implemented, but apps need to opt into it. It's not done for all apps by default automatically. If you think that should happen, please file a new bug report for it, so we can discuss it separately.
So do other DEs simply not care about the resident hint or what? If it's not causing them any problems maybe we should do the same.
Regarding the specifications ( https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html#hints ), they use two different boolean values, `resident` and `transient`. The first states that "The notification will remain resident in the server until it is explicitly removed by the user or by the sender", but doesn't clarify whether that means "visible on screen until dismissed" or "held on the notifications tray until dismissed". The second boolean, however, leads me to believe there is a difference between them, as a transient notification will "by-pass the server's persistence capability, if it should exist." The specs seen to leave the implementation for notifications not marked as either transient or resident (that is, the default) up to each specific server's implementation.