I know this was changed by design, but many people miss this feature from KDE4. I know the most history was filled with unneeded 'Now playing' etc notifications, so I offer to have a checkbox, for which applications save the history. I know there is some dev option to make it permanent, but no devs are using it, so I offer to have this checkbox with default value developer defined, and ability to change it by user. There is much discussion about this since Plasma 5.4: https://github.com/blue-systems/plasma-5.4/issues/48 https://github.com/blue-systems/plasma-ideas/issues/35 As you can see, many people misses old behaviour. Thanks. Plasma is the best.
I agree and would like to see it again. Making notifications like this makes them useless if you are distracted/doing stuff in fullscreen/out of the room. Please make them persistent again.
Thanks for the report Please always try to use search first *** This bug has been marked as a duplicate of bug 342260 ***
It's not a duplicate. 342260 is about persistent ones. Please stop going around the issue, there's clearly demand for this feature.
https://community.kde.org/Plasma/Notifications It's on the agenda (cf crazy ideas section) but not a high priority. Marking as confirmed to reflect that.
That's neat, thank you Kai. ...Although not precisely something I'd call a "crazy" idea.
(In reply to Andrew from comment #3) > It's not a duplicate. 342260 is about persistent ones. > Please stop going around the issue, there's clearly demand for this feature. Please remember this is free software, you're not entitled to anything and we don't owe you anything. Nobody is going around the issue, closing a bug as a duplicate means other people have already filed the same bug and you didn't bother searching first.
Lets not create an us vs them atmosphere. The root problem is that some apps emit non-persistnent notifications for status changes which are not temporary. Apps have multiple ways they can do that: - SNIs, NeedsAttention window status, or simply using the explicit "Persistent" flag which is already built into the notification spec. Personally, I don't think a config to just keep everything around helps much: - If a user has it off They miss the notifications as before - If a user has it on They get drowned in spam...and probably still misses important things because of that. Neither is great. I would like to see more people saying *exactly* what things are problematic so they can be fixed at the root cause - the relevant app. That's the only thing that makes everyone's experience better.
The list of problematic apps may be big. Devs didn't implemented 'persistent' by spec, because in KDE4 all was persistent. Someone use Evolution, someone Claws Mail, Thunderbird, qTox, uTox, toxic, pidgin, etc. So just adding a checkbox per app 'Persist notifications' will solve the issue. You can check thunderbird, qTox or any other app and be happy. And don't wait while developers will implement 'persistent' notifications by spec. It may be also be useful to temporary remember history of missed notifications while away or fullscreen
> So just adding a checkbox per app 'Persist notifications' will solve the issue It will not for the reasons I literally just stated. I'm trying to help understand the problem. I'd rather have you work with me than against. Pidgin's icon goes purple when there are new messages. I would like to hear specific issues that affect you, not a random list of untested hypotheticals.
Sorry if I misunderstood you. For me, the most annoying is that I loose Toxic notifications. It is console tox.chat client (skype alternative), that nave implemented X/DE notifications. Maybe qTox and uTox have same issue, I didn't tested. I need always to reopen my toxic to see, if I have new messages. For thunderbird, I temporary solved it by installing an addon, that shows a systray icon. The other reasons people described in these 2 links, provided in first post. I don't know how notification system is implemented, if some non-QT app send X notifications, kde will show it. Have X/GTK implemented persistent feature? or it is Qt/KDE specific? I receive many notifications and never saw any persistent in plasma 5. Other subscribed people, please join the discussion.
To me, the most annoying case of disappearing (temporary) notifications are those about newly arrived mails in KMail. I have a bunch of filters to dispatch incoming mail to different folders and whenever I turn my attention back to my pc I have to look through a bunch of folders just to see if anything went by unnoticed. I opened bug 368346 so someone could address that but it did not receive any attention. In https://community.kde.org/Plasma/Notifications the topic of this bug is filed under "crazy ideas" which I believe to be inappropriate. On the other hand there´s this statement on that page that I consider totally weird: "... but having [notification about completed file transfers] persistent makes no sense, because if you return to your PC after a while and see neither an ongoing file transfer nor an error message, you know it has completed successfully." I mean, seriously?? Like, getting distracted by a phone call while copying a bunch of files individually, and than having to remember (or look up) which ones I already processed and which not... Downloads in a browser are the closest analogy I can think of for this - and every browser I´ve used keeps a list of completed downloads around. I think it is hard to precisely define which notifications to keep in a backlog and which to discard and that makes me believe that a "keep all until dismissed" config flag would indeed be helpful (in combination with a "clear list" and perhaps a "remove this and all older notifications" button) if only because we will not reach an agreement between application developers and users either in the near future or at all. Yes, it has it´s drawbacks. But if it´s implemented the user at least has the chance to decide if she´s willing to accept the drawbacks in order to gain the benefits. Being bossy and telling the users what´s right for her has never been the KDE way (which does not mean that pre-selecting some option to nudge users in a certain direction isn´t acceptable and a valid strategy).
Ok, if you don't want change the design about persistence, for me the acceptable way will be: define notifications expiry time per app. i.e. I am sitting on my computer every day from morning to evening. I define kmail and chat notifications to have expire time 1d, or until I click them in notification list. If expire=0 - until click :) That way I will not miss them and they are not persistent. For Popup OSD message we may add an option to persist while not expired notifications exist, and shows latest, until click or until expire.
Two more cents: we see the trend for notification systems in all OSes, especially mobile. Each ios and android new version pay much attention to that. By the logic, as KDE is the best DE and is actively developing Plasma Mobile, the notification system must in Plasma be the best and most configurable from all these mentioned ;)
Thanks, #10 and the start of #11 are exactly what I was after. Bug trackers work when we understand the problem, being told to implement a solution without that won't get anywhere. As for your question: Persistence has been in the spec since forver, and yes it is implemented on GTK. It might be dubbed "expiration timeout" or "expires" i.e "notify-send -t 0 hello world"
Issue: Applications that uses temporary notifications when the user want them persistent. My Idea to solve the issue: notification client -> kde notification server --> display \ \-> *whatever So basically, kde notification server could display the notification *and* forward it via dbus to another registered receiver. The receiver itself could be another desktop widget that manages notifications in different ways (per-app filtering and so on) or just a script that stores them in a text file, whatever. The pros of my solution is that new (users made?) notification manager could arise in different flavours. Still, i'd be fine with per app settings integrated in plasma.
[ doubled from https://github.com/blue-systems/plasma-5.4/issues/48 ] This one needs my two cents, since I've spent a couple hours looking into it and reading this forum. I often notice a pop-up with buttons on it, just as it disappears. Was it important? I can't say, but apparently the developer didn't think so. Can I refer to the application for a clue? No, because I have no idea what it was about or what application produced it. This is annoying. Meanwhile I have yet to see a persistent notification after a year with KF5. The systray notification icon is apparently there to take up space and get me to spend time looking into the apparent problem. This could use a little work.
Just tried 'notify-send -t 0 hello world'. Yay, my first persistent notification. Or was it? It was gone when I looked a little later. Is that expected or reasonable behavior?
On further thought, I don't see a problem with treating notifications more like syslog entries; keep 'em all around for a year or whatever. Then, the notification UI would be a matter of what to display and how to display it. You could have defaults, application developers could express a preference, but the user could pull up counts on all their unique "Now Playing" entries, etc. Syslog facilities could be directly involved, or maybe akonadi would be a better choice.
Moreover, right now notifications stop working during day, then work again. It happens more than 1 month. I am using Kdevelop with FISH and click 'Save' every 5-10 minutes. Sometimes they appear, sometimes they stop working, and after some hours start working again. I use all latest built on gentoo from kde-overlay, unmasked all updates.
I'd just like to comment and say that I also want permanent notifications option because I want to use an email notifier tool that sends notifications but not having the ability to check what notifications have happened makes it worthless. I do think it should be an option and there could be a need for a redesign of how it functions. My Suggestion: 1. Leave the notification area the same size it is now. 2. Add option for permanent notifications. 3. Add a "Manage Notifications" (or something) button. 4. Open new window that contains all of the notifications that have been marked as permanent, organized by the application that initiated the notification. I can do a design mockup of this idea, if interested.
I would like to point out that notification are already configurable on a per application basis in that you can show a popup message or not, play a sound or not, etc., or run a script that can presumably use a different notification system. ;)
Or log to a file you can tail in console.
>I would like to point out that notification are already configurable on a per application basis in that you can show a popup message or not, play a sound or not, etc., or run a script that can presumably use a different notification system. ;) That's only partly true. KDE apps have configurable notifications Plasma has to cater to all apps.
(In reply to Tom Hardy from comment #21) > I would like to point out that notification are already configurable on a > per application basis in that you can show a popup message or not, play a > sound or not, etc., or run a script that can presumably use a different > notification system. ;) As David Edmundson said, this is not applicable to all applications and in fact most applications. Only apps that develop specifically to support this level of customization is applicable. I'd say that around 70% of applications that I've tried do not support this.
+1 yes very annoying that i have regressed in this regard since installing plasma 5. But as usual when i look up why things are missing etc i find a bug thread thats years and years long without progress :(
To me #11 and #12 sound like the issue is mostly with notifications that were missed while the user has been away for a while. Maybe we could check for user activity (KIdleTime) and trigger all notifications when resuming from idle.
Anyway an expiable notifications log, available by clicking systray icon would be great... Just like Klipper. And ability to uncheck the checkboxes in settings for clementine, amarok, vlc etc to ignore them in log. Seams easy to implement and will satisfy mostly all people
Some proposals: https://phabricator.kde.org/D7271 https://phabricator.kde.org/D7256
fixed in https://phabricator.kde.org/R120:28d86ab4356737260e054009795e595fbb069158
The bug keyword usage is: BUG: ###### Then the bug will automatically get closed on commit, and a link to the git repository added.
I upgraded to Plasma 5.12 specifically to try this fix. However, what I'm seeing is that even though non-persistent notifications are added to the notification history, they do not cause the counter in the system tray icon to increment, nor give any other visual cue that there are new notifications in the history. So, for example, if I step away from my computer for a while, and someone sends me an IRC message, the resulting notification that Konversation generates is added to my notification history, but there's nothing to indicate that I have a new message when I come back, unless I explicitly click on the system tray icon and check the notification history. Am I not using / configuring the feature correctly? Otherwise it doesn't seem like much of an improvement over the previous state.
Totally agree with Nathan, it is still not useful without icon count of missed notifications. reopening
Also it would be good as solution to persist notification popups for important notifications like on apple mac os, until you click them and they animate to top. Notifications is the most important human-computer contacting interface, the next actions of human directly depend from notifications he received, how it is configured per app and etc. I offer to pay much more attention to notification system in plasma 5, especially per-app preferences
>it is still not useful without icon count of missed notifications I am not doing that. Closing
(In reply to David Edmundson from comment #34) > >it is still not useful without icon count of missed notifications > > I am not doing that. Closing Could you help us understand why not? And for the use case of missed IRC messages described in comment 31, what do you suggest?
Because if an IRC client needs fixing, it needs fixing. Notifications are for temporary things. SNIs are for pernament events We had this behaviour in Plasma 4 it was horrific. However, if you really want this behaviour, please see: https://store.kde.org/p/1227099
(In reply to David Edmundson from comment #36) > Because if an IRC client needs fixing, it needs fixing. FWIW, the IRC client in question is Konversation. I filed bug 392785 about making its notifications persistent. > Notifications are for temporary things. > SNIs are for pernament events Does using SNIs mean that each application that wants to display persistent notifications needs to have its own icon in the system tray? That feels wasteful in terms of screen real estate, when compared to a single icon to manage all notifications. > However, if you really want this behaviour, please see: > https://store.kde.org/p/1227099 Thank you, this is very helpful! I tried this and I can confirm that it preserves the Plasma 4 behaviour of having every notification increment the counter of the notification icon, in addition to remaining in the history.
The notification spec allows one to mark notifications as persistent; but instead of being in the nice GUI, it's up to the app. On konversation you'll find name highlights are persistent and have the behaviour you want for all messages. There's an open report on moving that (somehow) to the UI in frameworks-knotifications/knotifyconfig. I do want to work on that. Glad the store works. I'm happy for users to have solutions to whatever problem even if it doesn't come from us.
(In reply to David Edmundson from comment #38) > On konversation you'll find name highlights are persistent and have the > behaviour you want for all messages. Hmm, that is not what I'm experiencing. Using Konversation v1.7.2, in Settings -> Configure Notifications, for "Nick written", "Show a message in a popup" and "Mark taskbar entry" are checked. Nonetheless, when someone writes my nick, I see a temporary popup (if I happen to be there), but the notification counter is not incremented. Should I file a new bug about this?