GNOME Bugzilla – Bug 333176
new mail beep should happen once per mail check
Last modified: 2013-09-13 00:51:22 UTC
Currently evolution will beep once per folder it finds a new message in. This could lead to 20 beeps per check, which can be quite annoying. A policy of just beeping once per mail check if any new messages are found seems a bit more sane. Evo also beeps when sending email, because you know, new email is hitting your outbox... And for even more joy.... moving an already read message to another folder will envoke a beep. Other information: These folders I speak of are IMAP folders, except when sending as that goes to a local folder.
jesse, do you think this is a duplicate of bug 300604?
Seems like it could be, but that bug seemed specific to evolution-connector, and isn't getting a lot of attention. Since I'm just using IMAP and not the connector it seems to be a farther reaching problem. Perhaps the first bug needs to be moved back to evolution itself, rather than connector.
I also have this problem using an IMAP mail server. Any time you move any bit of mail anywhere you get a beep. This problem appears to have been around for a while since I'm using version 2.2.1.1 on Ubuntu hoary.
I'm not sure that this report is actually a duplicate of any other bugs in bugzilla, tho the bug Andre pointed at above is somewhat related. The bug linked in comment #1 is that Evolution currently plays a sound (beep or otherwise) whenever a folder gets new messages delivered into it, whether it be that the message was just now entered into the user's mail system or whether it was only just moved from some other folder (filters? manual move?). Jesse's bug is that Evolution doesn't limit itself to playing said sound once per "new message scan" and so every folder that has had messages added to it (new mail or moved) will play a sound - which could be quite a few beeps if you have a multitude of folders/accounts or both. what should probably happen is that the play_sound functionality should probably be put in a timeout such that as more folders get their update signals and decide they got new messages, instead of playing a sound - they can check the timeout id, if still active - noop, else queue a new timeout. If the timeout is large enough (obviously we don't want too large), then all the folders should get their update events before the timeout expires, and whallah - crisis averted (mostly... altho this isn't by any means a perfect solution, just a practical one).
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 311512 ***