Bug 368346 - Add configuration option to set notification expiration timeout
Summary: Add configuration option to set notification expiration timeout
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-06 17:41 UTC by jansen
Modified: 2017-08-11 21:06 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.7.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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