GNOME Bugzilla – Bug 653699
[mail-notification] improve mail notifications
Last modified: 2021-05-19 11:44:48 UTC
We need to design and implement a better mail notifications experience. We also need to clean up the mail notification plugin configurations dialog. I'm currently only getting one notification for one new e-mail that I receive when I start Evolution, and don't get any subsequent notifications, though a sound does get played. I'm not getting subsequent notifications regardless of whether there is an item in the tray indicating a previous message or whether it got cleared because I have switched to the Evolution window (and then switched away). We should not have an action named "Default" displayed in the notification. What we should do about that depends on bug 653112. We should also consider including other actions, such as "Mark as read" and "Delete", as proposed in bug 648471. As for the configuration dialog, "Show icon in notification area" and "Popup message together with the icon" options should be removed. "Generate a D-Bus message" option should either be removed or explained.
Created attachment 190978 [details] Evolution notification with "Default" action
Created attachment 190979 [details] Evolution notification plugin configuration dialog
(In reply to comment #0) > I'm currently only getting one notification for one new e-mail that I receive > when I start Evolution, and don't get any subsequent notifications, though a > sound does get played. I'm not getting subsequent notifications regardless of > whether there is an item in the tray indicating a previous message or whether > it got cleared because I have switched to the Evolution window (and then > switched away). I believe it's currently written to show only one notification at a time. The notification can be cleared by invoking the "Default" action (which I agree needs to change), or by explicitly selecting a message in the Evolution window. Merely focusing the Evolution window isn't enough to clear it. > We should also consider including other actions, such as "Mark as read" and > "Delete", as proposed in bug 648471. Agreed, that would be useful. For single-message notifications, "Group Reply" and "Forward" might also be useful. > As for the configuration dialog, "Show icon in notification area" and "Popup > message together with the icon" options should be removed. I'd prefer we reduce this to something like "Emit a notification message", so that notifications can still be disabled.
Is this still just vague ideas, or concrete enough yet as a plan ? - Add 'Mark as read' and 'Delete' actions - Make 'Default' not show up (not sure what that involves, exactly) - Reduce plugin configuration to just 'Show notification'
The concrete plan should be as following: 1) Implement single message notifications showing up whenever a new message arrives and notifications are enabled. 2) Remove the "Default" option or give it a different name, such as "View Message". 3) Replace "Show icon in notification area" and "Popup message together with the icon" options in the configuration dialog with "Show notification " or "Show notification when a new message arrives". Make it consistent with the name of the option to play sound that can either be "Play sound" or "Play sound when a new message arrives". The reason I'm not sure if we need "when a new message arrives" in these strings is because ""Generate a D-Bus message" option doesn't have that and just implies that it will happen when a new message arrives. The ideas are as following: 1) "Generate a D-Bus message" option should either be removed or explained. Why is it necessary? 2) Add some subset of "Mark as Read", "Delete", "Group Reply", "Forward" options to each notification.
The deal with the "Generate a D-Bus message" option is it was added some years ago by Jean-Yves Lefort for his "Mail Notification" applet [1], which I guess isn't even usable now under GNOME Shell. This was back when we had three different plugins related to new mail notifications. Eventually we combined them all into what's there now. Certainly the check box should be removed. I guess for the time being we'll silently continue emitting the D-Bus message. The last release of that applet was in 2008, so it's probably safe to say the project is abandoned. [1] http://www.nongnu.org/mailnotify/
I ported the popper mail notifier to GNOME 3 to have basic mail notifications. Its available here: https://github.com/pulb/mailnag There's an issue with the way gnome-shell displays messages though. Details are available here: https://bugzilla.gnome.org/show_bug.cgi?id=648243
I made some progress on this. (In reply to comment #5) > 1) Implement single message notifications showing up whenever a new message > arrives and notifications are enabled. I'm concerned a separate notification for each and every new message arrival would quickly get overwhelming. Plus we don't have the infrastructure for it at the moment. I did, however, change the logic to redisplay an unacknowledged notification with an updated message count when additional messages arrive. Example: - Suppose a notification appears announcing 3 new messages in Inbox. - User does nothing, notification persists in... whatever the lower right corner is called. - Shortly thereafter, 2 more messages arrive in Inbox. - Same notification is shown, this time announcing 5 new messages in Inbox. - User acknowledges notification, new message count is reset to zero. > 2) Remove the "Default" option or give it a different name, such as "View > Message". I changed the label to "Show $FOLDER_NAME" where $FOLDER_NAME is the folder of the most recently received message. Further thoughts on this in the next comment. > 3) Replace "Show icon in notification area" and "Popup message together with > the icon" options in the configuration dialog with "Show notification " or > "Show notification when a new message arrives". Make it consistent with the > name of the option to play sound that can either be "Play sound" or "Play sound > when a new message arrives". The reason I'm not sure if we need "when a new > message arrives" in these strings is because ""Generate a D-Bus message" option > doesn't have that and just implies that it will happen when a new message > arrives. Done. > The ideas are as following: > > 1) "Generate a D-Bus message" option should either be removed or explained. Why > is it necessary? Removed. > 2) Add some subset of "Mark as Read", "Delete", "Group Reply", "Forward" > options to each notification. Not done yet.
Further thoughts after hacking on this a bit: * The top option in the configuration section is worded awkwardly. Would radio buttons make things clearer? (o) Notify me of new messages in Inbox folders only ( ) Notify me of new messages in any folder * The "Default" (or now "View $FOLDER_NAME") action is supposed to present the main Evolution window, switch to mail view, and select $FOLDER_NAME. However when I tested this all I got was another notification saying "$WINDOW_TITLE is ready." I'm using gtk_window_present() in the action callback. Is the shell or libnotify getting in the way, or am I gonna need to spawn another Evolution and let GApplication do its thing? * The current single notification scheme we have doesn't handle multiple accounts or notifications from multiple folders very well. I'm wondering if we should have a separate notification per folder. Each notification would have its own running count of new messages in its folder, its own "View $FOLDER_NAME" action, and its own "Mark as Read" and "Delete" actions which would only apply to the new messages it that folder.
Created attachment 191187 [details] [review] Unfinished patch My progress as described in comment #8.
(In reply to comment #9) > Further thoughts after hacking on this a bit: > * The top option in the configuration section is worded awkwardly. Would > radio buttons make things clearer? > > (o) Notify me of new messages in Inbox folders only > > ( ) Notify me of new messages in any folder I think this would be clearer, yes. > > * The "Default" (or now "View $FOLDER_NAME") action is supposed to present > the main Evolution window, switch to mail view, and select $FOLDER_NAME. > However when I tested this all I got was another notification saying > "$WINDOW_TITLE is ready." I'm using gtk_window_present() in the action > callback. Is the shell or libnotify getting in the way, or am I gonna > need to spawn another Evolution and let GApplication do its thing? This seems to be an orthogonal issue. These 'FOO is ready' notifications also frequently annoy me when clicking on links. Might be worth filing a separate bug about. > * The current single notification scheme we have doesn't handle multiple > accounts or notifications from multiple folders very well. I'm wondering > if we should have a separate notification per folder. Each notification > would have its own running count of new messages in its folder, its own > "View $FOLDER_NAME" action, and its own "Mark as Read" and "Delete" > actions which would only apply to the new messages it that folder. I don't know. Notification per folder sounds scary to me.
(In reply to comment #11) > I don't know. Notification per folder sounds scary to me. Notifications for ALL my folders scares me too. I'd prefer to pick and choose which folders will trigger notifications rather than choosing between Inbox or everything. But even if we stick to the Inbox-only case, consider having multiple IMAP accounts, each with their own Inbox. Actions like "Delete" or even "Mark as Read" become dangerous if the notification message doesn't accurately describe what messages the actions will apply to. And that gets difficult to do if the messages are arriving from multiple sources. Splitting the notifications by folder seems like the cleanest way to deal with this. But I won't know if that makes for a good user experience until I actually play with it.
I agree with mbarnes and mclasen on folders: for those of us with complex setups, being able to choose which folders we get notified for is the only practical method, I think. Or at least something smarter than a binary choice. To give a practical illustration - I have several dozen mail boxes, mostly for different mailing lists, but also one for Facebook mails, one for eBay/Paypal mails, one for status mails from systems on my network, one for mail to my Mandriva personal addresses, one for mail to my Red Hat personal address, one for mail to my Fedora personal address, and so on and so on. If I were notified every time any of the several dozen mailing lists I'm subscribed to got a new message the notifications would be so frequent as to be worthless, but I'd quite like to know when I get a new mail to my redhat.com address, for instance. And there might be *some* low-traffic, high-important lists I'd want to be notified for (fedora-announce, perhaps). If each one had its own separate notification stream it'd rapidly become unmanageable. So I'd definitely prefer a 'specify exactly what folders to be notified for' option. Another thought: when you click on the 'you got mail!' notification right now, it just switches to the Evo window; it leaves whatever folder and mail you currently have focused there open. I think it should pull up the folder and mail being notified about. If I just want to switch to Evo, I can do it via alt-tab or the overview. If I click on the notification, it kinda implies I want to deal with the mail I'm being notified about.
just as a coda to the above, before anyone objects 'but we're not making a desktop for people with three hundred mail folders!', anyone still using a dedicated mail client at this point in time is probably a fairly sophisticated user of email. People who aren't that, are probably using gmail, via the web interface.
Not sure what ui-review you're looking for but what I expect from mail notifications is pretty simple. * notification of mail in my inbox * (optionally) notification of mail in other folders * don't bother showing what folder the message is from in the notification * don't tell me the account for which the message was received (especially if I only have one account set up) * for a single mail notification tell me who it is from and a bit about the subject * for multiple new messages since the last notification just tell me how many and I'll go to the inbox to view them (there just isn't enough room to use the tray as a mail reader) * the notifications should use app icon and name (ie. not generic "new mail") * the action on the notifications should be: * show message for single message notification (even if already open) * show inbox for multiple message notification (even if already open) * forget adding any of the delete spam etc functionality - that belongs in the app
(In reply to comment #15) > * for multiple new messages since the last notification just tell me how many > and I'll go to the inbox to view them (there just isn't enough room to use the > tray as a mail reader) An IMHO interesting point to possibly improve: - I receive a notification for a new mail, and from the subject/sender I know I don't care - I continue working on something else - I receive a notification for a second new mail FAIL: currently, the notification does not say anything about the subject and sender of the second mail. So I need to switch to Evolution only to discover I still don't care about this second mail. Suggestion: for multiple new messages since last notification, show information about the new message that triggered the notification, and mention "+ X other new messages". What do you think?
Comment on attachment 191187 [details] [review] Unfinished patch "Unfinished patch" plus using gconf --> needs-work status
Personally I mostly only care about notifications for stuff that comes into the "inbox" folder, because all the rest that gets autofiltered server-side to other folders is by definition less important (or "bulk" mail). As Milan suggested above, simply adding more details in the current notifications (actual sender & subject of new mails) would go a long way.
Has any progress been made on this? Is this enhancement still on the road map? After having used Evo in work for about 6 months now, my biggest disappointment with it is the uninformative, seemingly unconfigurable "New mail in Evolution" pop-ups. If nothing else gets improved, I would at least like the ability to configure Evo to only show pop-up notifications for email that arrives in my Inbox and no other mail folder. Ideally the user would be able to choose which folders generate pop-up notifications upon receiving new mail and the new mail count be improved to show new mail per folder. It would also be nice if pop-ups for singular new emails showed the sender and the subject line within the pop-up.
(In reply to Dan MacDonald from comment #19) > Has any progress been made on this? All progress can be seen in this task. Picking up patches and improving them is highly welcome! > Is this enhancement still on the road map? I don't think it ever was.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.