Bug 368346

Summary: Add configuration option to set notification expiration timeout
Product: [Applications] kmail2 Reporter: jansen
Component: generalAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: wishlist CC: chgonzalezg, leoni.massimiliano1
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.7.0

Description jansen 2016-09-06 17:41:40 UTC
With KDE/Plasma 5 a change was made to the notification system which keeps desktop notifications from being saved in the notifications history unless they´re explicitly marked as "persistent": cf. the discussion at https://github.com/blue-systems/plasma-5.4/issues/48

To me, this is a rather annoying behavior especially with notifications for incoming mails (mine are sorted to a bunch of folders automatically and if I did not read the notification I have to go on a hunt for the new mail...).
Other people have similar complaints in different situations; e.g. see Bug #356657.

Since the notifications protocol mandates that the app sending the notification is responsible for the timeout I´d suggest adding an appropriate option to the KMail configuration.

The behavior of "notify-send" when used with the "-t 0" switch makes some sense: it shows the notification for a few seconds in a pop up window which then auto-hides while the notification is kept in the systray widget (notification history) unless dismissed explicitly.

On the other hand it might be even better if one could configure two timeouts: one for the pop up and one for the time the notification would be kept in the history until dismissed automatically (with 0 probably meaning: keep until dismissed manually by the user).

Reproducible: Always




I´m torn between marking this as a wishlist item and a bug because I consider it a regression...
Comment 1 Massimiliano 2017-04-11 15:00:18 UTC
I also acknowledge the existence of the issue. I use KMail to manage several different mail boxes at once, so checking the mail means looking into each of them every time.
I, too, miss the way it used to work before, but I'm not sure what the best solution would be, perhaps marking [or allowing to] notifications as persistent using the KFramework facility.
Comment 2 Laurent Montel 2017-08-11 21:06:56 UTC
Git commit 7c8ec7407bf312610431409b258736f71c636941 by Montel Laurent.
Committed on 11/08/2017 at 21:06.
Pushed by mlaurent into branch 'master'.

Bug 368346 - Add configuration option to set notification expiration timeout

Allow to define permanent notification or not
FIXED-IN: 5.7.0

M  +1    -1    agents/newmailnotifier/newmailnotifieragent.cpp
M  +3    -0    agents/newmailnotifier/newmailnotifieragentsettings.kcfg
M  +5    -0    agents/newmailnotifier/newmailnotifiersettingsdialog.cpp
M  +1    -0    agents/newmailnotifier/newmailnotifiersettingsdialog.h
M  +1    -1    agents/newmailnotifier/specialnotifierjob.cpp

https://commits.kde.org/kdepim-runtime/7c8ec7407bf312610431409b258736f71c636941