[notifications]: no history for certain notifications (example cantata: "now playing" message bubble is shown, but not kept), those were stored for later reading in kde4.x

[mck182]

This is a design decision we've taken with Plasma5 to conform more with the freedesktop notification specification we're using - only the persistent notifications are stored as they are marked persistent. Those that are not should not stay because the developer did not intend them to stay (they are not persistent).

Plus in case of media players, it makes no sense to keep a notification about a song played 30 minutes ago; it just fills the history with not useful and outdated data (and the history size is limited). For current song being played and/or player state, we ship the media player which shows all this info in real-time, no need to go to notification history for that.

[star-buck]

Can we add an option or hidden config to restore kde4.x functionality? Imo its incredible useful to for example have a "radio station streamcast" playlist of songs played in case i just tuned in or somehow missed the current bubble...

[mck182]

I think the notification history is the wrong tool for that purpose (if only because the popup is so small). What would be better is to have a proper playlist history in the media player applet. It is where such functionality belongs after all.

Then there could be a nice list like eg. http://www.last.fm/user/mck182/tracks?view=compact&page=1

[star-buck]

Last.fm is a centralized, webbased datacollecting service, thst tracks authenticated users playlist. A simply stream doesnt know user nor does it store something, think of radiotray. Why put the burden on each available streaming music app, when the system provides a nice mechanism anyway for providing notifications and storing them for later viewing? Why by the same logic then think further about akonadi and other such kde components, which also offer a common service for applications to use? Virtually every music app offers a way to share notifications with the underlying DE, as a centralized and convenient way to not implement this service each on their own. So the incredible useful function to not need to haste and note down each track while listening to a stream (the same convenient knowledge you have to look up a song up later if you know theres a playlist stored so you neednt immediatly get out shazam and track it until the song ends) is just very convenient. There are also other notifications that are just handy to have. We could allow the users to keep only important or also less important messages, or think about doing a very good notifications system which keeps track of messages on a per source method. The current notification method seems imo worse in decision making, and determening ehats important and whats not only ever catches 50/50 (while it may have some value for a newbie, for a longer term kde user those "plasma or widget deleted" notifications are really annoying...).

[mck182]

I think you misunderstood the point, let me try re-explaining.

Currently whenever there is an mpris-enabled player (all linux players are, Cantata included) playing any music, the media player applet gets automatically activated in the systray. The media player applet knows precisely which song is being played, it also has access to all the other song metadata. Whenever a song changes, media player applet knows about it. So why not put the history functionality there directly, where it belongs? The last.fm chart was just an example of how it can be/look like inside the media player applet, not a suggestion to use instead.

The media player applet would keep the list locally and would display it whenever, with proper time of playing etc.

The notification history is automatically cleaned after a timeout and is limited to only couple entries and will not persist after logging out. It's really not a system meant to be used as a playlist history keeping.

So the incredible useful function to not need to haste and note down each track while listening to a stream

No need, the media player applet is showing the currently played song, whatever is the actual source (works with streams too). That's what the mpris interface is meant to be used for.

The current notification method seems imo worse in decision making, and determening ehats important and whats not only ever catches 50/50

It is not determined by the applet, but by the application developer. That would for example be Cantata. If they are not using persistent notifications, I believe they have a good reason for that.

Generally speaking, in case of something needing an attention longer than the life of a notification bubble, it should put new entry in the systray area rather than putting everything into a bubble. That's what we decided with Plasma5 and changed things to go along with that (eg. the freespace notifier is no longer a huuge notification but rather a systray icon happily popping up).

[davidedmundson]

Upstream report: https://bugs.kde.org/show_bug.cgi?id=342260

[star-buck]

@mck182 : I understand the idea of freedesktop, just doubt its practical (nor wise) for program creators to decide if messages are to be stored as history in notification area or not. I think the better (and formerly implemented) idea is that people assume notifications which show up will be added to the notification area as kind of history...and therefore also control which messages they want to pop up or not. To seperate between showing up and showing up and being stored is making everything too complicated imo, therefore one could assume any messages the user find valuable to show up at least have some merit to be worthy for history for further reading in case the user is not at screen, wants to be able to look it up later etc. I'll at least start to have a look if music player notifications get also stored after shown up as bubble as "1 message" in the notification area systray for later reading, so we can see if other major DEs besides KDE (Gnome, XFCE, Cinnamon) do store messages regardless of their "freedesktop status". That simply means that it likely is expected behaviour for any message to be important enough to be set by the user to show up (which most music players allow setting on or off already) to also be available for later reading. To satisfy both freedesktop recommendation and expected behaviour controllable by the user (and not the creator of each program to decide whats important and what not), a simply solution could be a "keep all messages as history" TICK option.

[mck182]

I understand the idea of freedesktop, just doubt its practical (nor wise) for program creators to decide if messages are to be stored as history in notification area or not.

That's not true, the specification is there and the developers are expecting that the systems implementing the specification will behave according to the specification. If we cannot guarantee the features specified in the specification to the developers, the spec itself becomes pointless.

one could assume any messages the user find valuable to show up at least have some merit to be worthy for history for further reading in case the user is not at screen, wants to be able to look it up later etc.

The application developer knows the best which notification is valuable (and we have the HIG to help out). If it is important enough that the user must see it, the developer can use persistent notification or better, the StatusNotifierItem (and this is the case around KDE apps).

'll at least start to have a look if music player notifications get also stored after shown up as bubble as "1 message" in the notification area systray for later reading

I still maintain my opinion that using notifications for playlist history is using the wrong tool for wrong purpose. As I said previously, we have better tools better suited for this kind of usage. Why not take advantage of them and put the functionality where it belongs?

we can see if other major DEs besides KDE (Gnome, XFCE, Cinnamon) do store messages regardless of their "freedesktop status".

I actually did check; XFCE has no concept of history at all. They do follow the freedesktop specification quite precisely - persistent notification bubbles simply persist on the screen unless acted upon.

Gnome is a bit of hybrid and turns some notifications into StatusNotifierItems, but it's a bit broken (to see them you have to use the "activities" overview and some have no icons so you've no idea where they are). Media player notifications do not get stored anywhere at all.

Cinnamon does store all of them, though in their default configuration it says "ignore transient notifications" (ie. store only persistent) but that seems broken afaics. Or I understood "transient" in Cinnamon wrong. UPDATE: The notifications do disappear after certain time from the history, unless they are marked as persistent.

Unity also has no concept of notifications history. Their notifications generally are quite limited.

---

Can you think of any other notifications besides media player ones that the user would want to keep in the history (and why)?

[thugcee]

Can you think of any other notifications besides media player ones that the user would want to keep in the history (and why)?

I can think of many such notifications. I have just switched to Plasma 5 and lack of notifications history is one of two biggest minuses compared to KDE4.

example: I leave my computer to make a coffee or I watch a movie in full screen mode and then I go back to desktop and I want to know:

• if any emails have arrived in mid time,
• if there was any bell on one of many of my console sessions,
• if backup script have finished successfully,
• if log watcher have detected something unusual,
• and I can go and go with such examples.

And you say that it's now better, that every time I stop watching desktop for a moment, I have to check all notification sources to make sure I have not missed anything. For me this is stupid.

I have switched to KDE because its developers, instead of forcing ideas, they were giving its users freedom. Please do not go the same way - "the one correct way for all" - Gnome and Unity have come.

[antonvinny]

Just migrated from KDE 4 and really missing this feature. An option to enable the notification history would be a great feature.

[Houston4444]

I really agree with thugcee. It should be really, really better to let user choose and keep an option to get a notifications history. And I didn't find any option to make a persistent notification with a shell script (Not possible with kdialog for example). If a script make new files and user don't see these files, now he will never find them.

[ManIVIctorious]

This is really annoying. I just missed 2 quite important eMails and lost about an hour searching for this feature, just to realize it has been removed. Please let the user decide if he/she wants the messages saved, my mail client (geary) obviously doesn't think that an eMail notification should be persistent => maybe the developer doesn't always know best...

[christophschw]

Yeah, I do agree. I missed a lot of messages from kdeconnect and from my mailnotifier because I wasn't in front of my PC.

At the moment my notification icon is unused because there aren't any persistent notifications. Would be great to see a possibility to change the history behaviour. Thanks!

[ghost]

Clementine used to pollute the notification tray with many "Now playing..." notifications (when configured to use native notifications) Thus this is an improvement, not a regression. Thank you.

[Houston4444]

It's maybe an improvement for music players softs which don't choose OSD. But Notifications ARE NOT ONLY DONE for music information, but for emails, little scripts, new files on Dropbox, and a lot of things you NEED to know. The choice of devs is understandable, Don't let user choose is a regression.

[thugcee]

@konqoro Then Clementine should be fixed (to use OSD for example) instead of breaking notifications system.

[sfrique]

I agree with @thugcee, i need ot know if i got an email or anything when i get back to computer..

[ManIVIctorious]

@konqoro just use clementines OSD!

[christophschw]

@thugcee You're completely right!

[wintericie]

+1 for this issue.

[frasty]

Breaking the notification system just to let some audio player not to pollute it doesn't sound as a good idea to me. I have yet to see an application who does use persistent notifications, thus as of now the notification system is quite useless..

[magpie514]

I agree with @thugcee as well. Notification history is not very useful now. It's always empty.

[jayeshbadwaik]

While I agree that the default behavior should be to conform to the freedesktop standards. There should be an option by the user which overrides the default behvaior, simply because so many people want that option to be there.

[nortexoid]

Like many others, I don't wish the fate of my notifications to lie in the hands of random application developers! The user should have the option to keep a history of all notifications (or better, those she chooses). By the way, like KDE4, Gnome (3.18) DOES keep a history of all notifications, accessible by clicking on the time in the panel, with an option to dismiss all. Very useful!

[vindicatorr]

I want to +1 this as well. I just moved from Ubuntu 15.10 to Arch with KDE, installed KDE Connect and while notifications DO pop up from my phone, sometimes I'm engrossed in what I'm doing that I don't see them in time, or like others say, I can easily be away from my computer and not know anything came up because it isn't "persistent" in the notification history.

+1 for "user's choice". If, as a developer of this piece, you don't like the idea, just make the default choice to not retain all items in the history and only those with programs that enable persistence, but give the user that option to change it... unless you're just making this piece only for you... But there are probably going to be cases of dead programs ( skype) that won't even update with new system UI changes so notifications will never persist.

[colomar]

The KDE usability team has recognized that missing notifications is a problem, but we do not consider the behavior in Plasma 4 to be the optimal solution. I will try to get in touch with former leader of the team Celeste again, who happens to have written her PhD thesis about the topic of desktop notifications. If there is any one person who knows best how to solve this issue, it's her. I don't want to shoot a solution from the hip as that would be likely to please have of our users while annoying the other half, so please give us some time to come up with a good solution,

[star-buck]

@colomar: Thanks for giving it another shot. How about taking a look at how others solve this, like Gnome, Mint, Deepin, or even recent Windows10. As to technical how: A checkbox-option to keep messages present until manual discarded should solve the problem imo.

[colomar]

@star-buck Yes, looking at others will be part of the strategy. Getting scientific input will be another part, as Celeste already promised to look into it :) Providing a config option is possible, but should only be our last resort. First we should see if we can find a solution that works well for everyone.

[mck182]

Yes, looking at others will be part of the strategy

Fwiw, I did look at others a year ago, see the comment at the top. Will be interesting to see if any of those changed their implementation.

[sfrique]

@colomar I dont see whymaking a config should be the last resort. You could define the default for "everyone" but could give the choice for the people that don't want the defaut options.

The one thing KDE/PLASMA had it was that you could configure pretty much anything. As gnome has to opposing view that is not able to configure it all and use what they provide.

Thanks

Em qua, 3 de fev de 2016 às 15:57, mck182 notifications@github.com escreveu:

Yes, looking at others will be part of the strategy

Fwiw, I did look at others a year ago, see the comment at the top https://github.com/blue-systems/plasma-5.4/issues/48#issuecomment-68208241. Will be interesting to see if any of those changed their implementation.

— Reply to this email directly or view it on GitHub https://github.com/blue-systems/plasma-5.4/issues/48#issuecomment-179376772 .

[llelectronics]

Yeah I am also pro when it comes to making it configurable. The default should be like is (as this is basically the default on other desktops aswell. @mck182 basically nothing changed on the other desktops) If the applications don't make it easy to choose how their notifications are shown (persistent or not) then the desktop should allow such an option. It should be called "Save notification history" and have a combobox (the one with the numbers) where you can choose the maximum of notifications to be stored until the older ones get removed. Or it should be made configurable how long notifications in general are shown and then maybe stored for later reading. The overall best solution would be to have a global rules list where one can set which notifications to store persitent and which not.

[mck182]

As I said in my comments above - we have much better tools to actually do what you want from persistent notifications. It's called KStatusNotifierItem and it is sooo much better and offers sooo much more possibilities than a persistent notification. You should really all insist that apps make better use of these.

Anyhow the current systray popup fits about 2-3 notifications. It is not at all suited for serving as a notification history browser. It would get overloaded so quickly that it would become useless after about 30 minutes of desktop usage.

Finally,

The one thing KDE/PLASMA had it was that you could configure pretty much anything

You can't. It's a perception from the past where the user was drowned in an ocean of options. This is what we're trying to get away from, generally.

I dont see whymaking a config should be the last resort.

Because it brings complexity on all possible fronts, including maintenance, testing, bug handling, user psychology etc etc.

[colomar]

Configuration options are great if different people have different needs regarding an aspect. What we see too often in Plasma and KDE applications, however is the situation

• Version 1 (e.g. Plasma 4) did something in a way which wasn't really good
• Version 2 (e.g. Plasma 5) tried to improve the situation, but the solution wasn't really thought through
• People who found version 1 less of a pain than version 2 complain.
• We provide an option to switch between the two suboptimal versions.

This appeases those who complained about Version 2, but it leaves us with another config option and still no really satisfying solution. Sometimes, this is unavoidable. But sometimes, thinking a bit harder could have lead to a solution which serves everybody's needs.

Offering a config option is an "easy way out" which should not be out of the question, but should not be taken before thinking about a better solution.

In this case: Plasma 4 put all notifications in a history, which then became quickly so crowded that it was difficult to find the notification you were looking for in all the noise. Plasma 5 has a much more cleaner notification area, with the drawback that users may miss notifications which are important to them.

Before we offer users an option to just choose what's "the lesser of two evils" for them

[magpie514]

Maybe some sort of whitelist based on the dbus id of the emitter? For example the notifications I care the most about are from pidgin and my (self-made*) download manager, while the rest are OK if they disappear after a bit. I bet everyone else has at least a couple programs they care the most about.

• the self-made note is not to brag, but to discourage stuff like "only a list of popular applications".

[mck182]

my (self-made*) download manager

Since you're in control of your own notifications then, you can easily make them persistent. If you're using KNotification, just set the flag. If you're using the dbus api directly, you can set the timeout to 0. This is exactly what you should be doing as an application developer.

This is also btw another good example for using KSNI (and also for what it was invented for). With that you can have an icon in systray that is Passive when nothing is being downloaded. Active when it is downloading and NeedsAttention once it finishes downloading. The icon can also indicate progress and display other useful data. Its context menu can have full list of downloaded items with arbitrary actions. It is more code, sure, but well worth it.

We do have the tech for "Notifications 2.0", we just need to use it.

[vindicatorr]

Frankly I am (mostly) pleased with Android's (kitkat) way of handling notifications, particularly with the slickdeals app. Each app is a container within the notification container. Slickdeals may have multiple notifications come in, but instead of having an individual swipe-dismissal for each slickdeal, they are all contained within the slickdeal container, so you can either click (to open) or swipe (to dismiss).

You could take it a bit further by taking other suggestions into play. Like limit the app container size to fit a certain # of notifications for that app. Or have an app container display a # for the notification count for that app (program), along with the latest notification. The user can then click the notification where it will expand a certain distance and the user can scroll through the list, where specific sub notifications can be closed or the whole app container can be closed/dismissed.

I think I only have a handful of programs that submit notifications, so adding a scrollbar won't be too far reaching for such a small listing when each program is a container for it's own notifications.

[notmart]

@colomar an interesting thing would be the actual full text of her dissertation (even tough would be a looong read;) I guess depends from the rules there how much is freely distributable (for instance in Italy copyright goes to the university, but then goes on a license in which is freely consultable/readable, pretty much like any scientific paper not behind a paywall)

[colomar]

@notmart Here you go: http://contentdm.ad.umbc.edu/cdm/ref/collection/ETD/id/24842 And here is the gist of it condensed in a journal article: https://www.researchgate.net/publication/272373165_Interruptive_Notifications_in_Support_of_Task_Management So choose your own adventure ;)

[notmart]

damn, I have to read it now /o\ (and i will, at least in part ;)

[christophschw]

You can't. It's a perception from the past where the user was drowned in an ocean of options. This is what we're trying to get away from, generally.

Do we look like Mac-Users? ;)

[thugcee]

It's a perception from the past where the user was drowned in an ocean of options. This is what we're trying to get away from, generally.

There is a lot of desktops for users who can't swim. Please leave this one for power users.

[christophschw]

There is a lot of desktops for users who can't swim. Please leave this one for power users.

+1!

[nortexoid]

I don't know if people hadn't noticed, but people today are more proficient at using a computer, so more capable of understanding or avoiding configuration options. It doesn't make much sense to me to hear people (developers) arguing that we need to dumb down the user experience. What we need is a good balance given today's general proficiency level--which is pretty high!

[colomar]

An update on what others do:

• Unity: No history whatsoever
• Windows: No history whatsoever
• GNOME: They actually do have a history, but no indicator for it. Instead, if you click on the time, you get a popover with, among other things - a history of notifications, regardless of whether they were permanent or not. So they do allow access to the history without annoying the user about it.

[christophschw]

If I'm not wrong: Unity has some Plugin to store all notifications. And Windows (7) does not even have a notification Server. Nevermind...

Best would be if you could handle the behaviour on Server side. Which means the applications using libnotify would be registered and you could change the behaviour of each of them separately: timeout, persistent flag, command execution...

[star-buck]

Windows: no history when they introduced a completely sophisticated notification center in win10, that others already started copying like deepin or budgie? I dont have win10, but even regardless of others, lets bring back the functionality we already had in kde4.

[star-buck]

Win10 notifications area explained: http://www.pcworld.com/article/2965932/windows/how-to-customize-what-appears-in-windows-10s-action-center.html

[mck182]

I would like to point out that windows10 uses a whole screen-height sidebar for notifications.

Plasma has very very limited place in form of the rather small systray popup, which would make notification history quite an unpleasant experience to use.

And I would like to once again reiterate to consider KSNIs instead. They are much better suited for everything everyone actually wants from notification history.

[colomar]

Windows: no history when they introduced a completely sophisticated notification center in win10, that others already started copying like deepin or budgie?

Ah yes, sorry, I was only testing Windows 8.

[colomar]

Plasma has very very limited place in form of the rather small systray popup, which would make notification history quite an unpleasant experience to use.

Good point, but I'm at a point where I feel (not only because of notifications) that we're limiting ourselves too much with that fixed-size popup, to be honest.