Bug 340068

Thanks for the report

Which notifications in particular are being stored in the history? In Plasma5 only persistent notifications are put in the notification history because, well, they are marked as persistent. This is in control of the application.

Most notifications in Plasma5 were made not persistent and as such should not do any spamming at all.

Thanks a lot for the fast response!

So far, with my limited use of Plasma 5, completed file transfers are stored in the notifications history. I suspect that Kopete messages and network connect/disconnect notifications would also be stored?

> I suspect...

Well in the original report you stated "I strongly dislike the way that notifications for all events accumulate" so I thought you had more than just a suspicion :)

Completed file transfers will for now stay in the history. The use-case is simple - you're copying a big file which takes a long time and you leave the computer, after you come back you have a notification notifying you about a finished file transfer and also a button to quickly open the copied file or the folder where the files were copied.

Network connect/disconnect is not a persistent notification (at least wasn't last time I checked) and Kopete is not Plasma5 application, so if anything you should file a bug against Kopete for using persistent notifications (however they have a reason for being persistent...if they actually are).

---

Back to the original report:
> 1. An option to completely disable the notification tray widget

That could be added...maybe.

> 2. ... automatically expire completed entries after a defined number of seconds.

That is already happening, maybe the timeout could be lowered.

Thanks a lot Martin! I'll make a note here of any pesky notifications as I see them. (Sorry for the assumption that Plasma 5 would make all notifications persistent like in KDE4, which was a major problem. :) )

And thanks for considering these two possible options to make it more flexible!

So far it is behaving better than KDE4 did. But I do find it annoying 
that there is a persistent notification for every single file copied, 
even tiny ones that finish instantly. Maybe the auto-expire time could 
be set to be a percentage of the time it took to complete the action? Or 
else don't generate a notification if it takes less than 10 seconds or 
something.

Thanks again for looking into this, very much appreciated!

> there is a persistent notification for every single file copied, even tiny ones that finish instantly

With the old Plasma you could use a separate KIO window for file progresses, and it only popped up for longer transfers. Additionally, when it popped up, you had the option to check "stay open after finished", so if you needed to access the destination after a long copy, you could instruct it to not hide.

Has this functionality been removed in Plasma 5?

No, KIO still displays the full blown dialog if the notifications widget (containing the jobs too) is not active. 

However the option to track jobs /is/ gone from the applet. That should be added back.

(In reply to Martin Klapetek from comment #7)
> No, KIO still displays the full blown dialog if the notifications widget
> (containing the jobs too) is not active. 

Hmm, I couldn't get this to work. I tried un-checking the "Notifications" under "Extra Items" in the system tray settings, and when I copied a large file with Dolphin over smb:/ there was no progress notification anywhere. Am I doing something wrong? Thanks!

Created attachment 89214 [details]
Standard KIO copy dialog

Dunno, works here. Although I tried without running Plasma altogether, so maybe it's related to that.

I'll look into it.

Looking at the code, the notification applet itself puts the "Copying Finished" notifications there, it's not told so by any external means.
While those notifications are useful after a long transfer, they do not communicate any status ("Copying failed"/"Copying aborted") and appear even if the user explicitly cancelled an operation. I can understand the desire for an option to get rid of those notifications.

The best solution, of course, would be having KIO emit those notifications since it knows what happened (user clicked Cancel, etc) instead of blindly emitting a "Finished" notification whenever a job, for whatever reason, exits.

Well technically even if it's aborted/cancelled, the job is still finished ;)

It's on my todo to make the job notifications more clever, one thing I wanted to do as well is detect if the system is idle and if yes, make the notification persistent, if not, it would not be persistent.

Git commit 39045d5407c1a67c64e7f27074c012ea67124518 by Kai Uwe Broulik.
Committed on 06/11/2014 at 13:51.
Pushed by broulik into branch 'master'.

Alleviate the annoyance of Job Finished notifications

Whenever a job disappears for whatever reason (cancelled, finished, error, ...) we display
a persistent "Job Finished" notification. When the user explicitly cancels the job, there's
no need to confirm since the job will be gone. This solution is not ideal since we just track
it inside the plasmoid (ie. when you click Cancel in a "Override this folder?" dialog, it will
still show the notification) but at least the obvious "You don't say" moment is gone that way.

Ideally in the future whoever is responsible for the job (KIO, ...) should be given the
responsibility for an appropriate notification since the owner knows best why a job quit.

M  +5    -10   applets/notifications/package/contents/ui/JobDelegate.qml
M  +10   -1    applets/notifications/package/contents/ui/Jobs.qml

http://commits.kde.org/plasma-workspace/39045d5407c1a67c64e7f27074c012ea67124518

Git commit ba4fa4b2762fa9bf01ecbcb6f58d1a4448dea200 by Martin Klapetek, on behalf of Kai Uwe Broulik.
Committed on 06/11/2014 at 13:51.
Pushed by mklapetek into branch 'Plasma/5.1'.

Alleviate the annoyance of Job Finished notifications

Whenever a job disappears for whatever reason (cancelled, finished, error, ...) we display
a persistent "Job Finished" notification. When the user explicitly cancels the job, there's
no need to confirm since the job will be gone. This solution is not ideal since we just track
it inside the plasmoid (ie. when you click Cancel in a "Override this folder?" dialog, it will
still show the notification) but at least the obvious "You don't say" moment is gone that way.

Ideally in the future whoever is responsible for the job (KIO, ...) should be given the
responsibility for an appropriate notification since the owner knows best why a job quit.

M  +5    -10   applets/notifications/package/contents/ui/JobDelegate.qml
M  +10   -1    applets/notifications/package/contents/ui/Jobs.qml

http://commits.kde.org/plasma-workspace/ba4fa4b2762fa9bf01ecbcb6f58d1a4448dea200

I would mark this as resolved in 5.3 now because:
- You can turn off jobs and/or notifications independently
- When you cancel a job no "finished" message is triggered
- When a job fails it emits a "failed" rather than "finished" message
- These notifications are removed from the history after 10mins of user activity