GNOME Bugzilla – Bug 247373
Error messages are intrusive
Last modified: 2013-09-13 00:56:46 UTC
Description of Problem: When you set you mail to be checked every x minutes, if Evolution is unable to check your email, it will pop up an error dialog, which intrudes on any other work you are doing at the time. Steps to reproduce the problem: 1. Set your mail to be checked every few minutes 2. Unplug your {modem, ethernet cable, whatever} 3. Do something else in another window Actual Results: An error message pops up. Expected Results: The failure should be quiet, but noticable How often does this happen? Additional Information: I encountered this when I had left Evolution open on my laptop after the power had gone out (knocking out the DSL). I think the UI should be less intrusive. Maybe a notification in the status bar would be better. I think this would fall under the idea "if the user does not request something explicitly, dont annoy them with an error". Like you would not expect a pop up dialog from a cron job.
the problem with the status bar is that it will be wiped clean if some other action is done and so the user might not see the message. according to the HIG it is also not suggested to use the status bar as users seem to miss it visually or some such. I don't really see any way around using dialogs. All apps use dialogs for this sort of thing anyway... it's what users expect I'd say. I think you best email evolution-hackers@ximian.com with ideas if you have them so that our UI person can see this and discuss it with you. once an idea is agreed upon it can be re-submitted to bugzilla with maybe a link to the outcome of the discussion. How does that sound?
In #evolution: <dobey> in the context of 1.4, i agree with fejj's comment <dobey> in the context of 2.0, i'd rather have a background process that checked mail, separately from the main evo process, and that used the notification area or whatever
*** bug 249783 has been marked as a duplicate of this bug. ***
*** bug 250264 has been marked as a duplicate of this bug. ***
Retargetting all 2.0 reports for 1.5.x Please set new milestone if needed.
*** bug 240523 has been marked as a duplicate of this bug. ***
*** bug 262027 has been marked as a duplicate of this bug. ***
*** bug 222031 has been marked as a duplicate of this bug. ***
please also take a look at the comments on bug 222031!
*** Bug 301998 has been marked as a duplicate of this bug. ***
related to bug 300402 and bug 270682
*** Bug 270682 has been marked as a duplicate of this bug. ***
fixed the subject - the other had no meaning. removed eplugin keyword, eplugins have no control over error message display
*** Bug 269977 has been marked as a duplicate of this bug. ***
*** Bug 254382 has been marked as a duplicate of this bug. ***
*** Bug 303186 has been marked as a duplicate of this bug. ***
*** Bug 306925 has been marked as a duplicate of this bug. ***
according to duplicate bug 306925, this is against the HIG, therefore adding keyword. quoting Lakin Wecker from bug 306925: "From chapter 3 of the HIG 2.0 guidelines http://developer.gnome.org/projects/gup/hig/2.0/windows-alert.html: "Display an error alert when a user-requested operation cannot be sucessfully completed. Present errors caused by operations not requested by the user by another means, unless the error could result in data loss or other serious problems. For example, an error encountered during an email check initiated by the user clicking a toolbar button should present an error alert. However, an error encountered in an automated periodic email check would more appropriately report failure with a statusbar message." I have my email set up to check email every minute, and if there happens to be a problem during the automatic email checking procedure I don't want an alert popped up, as happens currently. Steps to reproduce: Open Evolution. Disable network connection. Wait until automatic mail checking is performed. Observe the alert which is shown."
In the context of a laptop a popup is entirely too severe. My laptop only connects on high-speed connections, so when I'm connected I want it to update quickly and regularly. However, I use evolution itself on a regular basis while on transit and in many other places where there is no net connection. The popup stops me from my work. I think the status bar is the place for the message. If other processes may overwrite this, then perhaps a portion of the status bar should be reserved for an icon which indicates whether evolution thinks you are online or not. This status indicator doesn't actually affect the way the application works(as is the case with the "work offline" button), but it does indicate to the user if the app has failed it's last attempt to connect to some server. And I refuse to click the "work offline" button, because a laptop is a sufficiently powered and sophisticated machine to figure out if it's connected or not. In fact, in the case of free wifi hotspots, the laptop is actually better equipped to make this decision. Why shouldn't the laptop send my queued mail when the train makes a stop at a station with free wifi. And why shouldn't it do this with no intervention on my part?
*** Bug 269281 has been marked as a duplicate of this bug. ***
*** Bug 310865 has been marked as a duplicate of this bug. ***
Apologies for any spam... cc'ing usability-maint on all Evolution usability bugs. Filter on EVO-USABILITY-SPAM to ignore.
Created attachment 49877 [details] the HIG mandates this ? A photograph of Alt-Tab - FWIW, there is only 1 mailer & calender open - the rest are error dialogs. Often it's even worse than this.
FWIW, the (draft) HIG also says: "An alert should not appear in the panel window list unless it is, or may be, the only window shown by an application. For example, an appointment reminder alert may be shown after the main calendar application window has been closed." So if nothing else, you shouldn't get all those errors appearing in the Alt-Tab window anyway.
Michael, Either I'm misunderstanding you, or you're misunderstanding my post. If indeed you're misunderstanding my post I should clarify. The quote from the HIG that I posted supports the argument of not wanting any error dialogs for automatic actions. The HIG says that the dialog should only be shown when you actively requested the action which failed. So if you click on Send/Received or press F9 to check your mail and it fails, you should see the error message dialog. However, if the action is automated, such as the automatic mail checking evolution does, then it should not pop up a message dialog. The error should be shown in a non-intrusive way.
Hi, I'm using Evolution 2.2.2 (Debian testing tree version 2.2.2-4) and if there is no network connection available, so Evolution could not reach the mail servers, a error/alert message will reiteratively pop up with no error message in it. Evolution should detect if there is a connection available and fall back into offline mode if not, so it doesn't disturb while working with Evolution offline. André
*** Bug 308764 has been marked as a duplicate of this bug. ***
Given the number of dupes this one seems like a valid issue to a lot of users. Thus raising Severity and setting a Target Milestone.
raise, raise, raise. hig violation.
Thinking aloud here, though I now think this approach is a bad one: if we accept that Evolution can't be smart emough about not showing certain error dialogs, then maybe we need to adding something like this combobox to error dialogs: +---------------------------------------+ | Error boiling the ocean | | Unable to connect to | | orbital.laser.mindcontrol.com | | | | [ ] Only show this error in the | | status bar from now on. | | | | [Close] | +---------------------------------------+ But I think this is something of a band-aid/defeatist approach; a better approach is to avoid showing the error dialog in the cases discussed in this bug, and use the status bar for such things.
Well for the specific case of network going down, The network manager support should make evo not check for mails when the network is down. So the premise of the bug would cease although i am sure that there could be other situations like if the server disconnected randomly or some such where a clear line of reasoning is required as to where to display the error message. I would like error on peroidic options like check mail etc be shown in the status bar, for one time error messages dialogs are valid enough but you would not want evo to pop up a error dialog peroidically.
To answer shres, if the server you are connecting is down, still we would come across such situations of multiple popups, which should be solved any way. Im sitting with my laptop unplugging and try to reproduce the error on head (evolution build) for the past 1 day, im not able to see it. Is someone still seeing this. I too use to face this issue. I see some code on mailer side which hints that this issue is fixed. <snip> mail-mt.c:mail_msg_check_error () if (active_errors == NULL) active_errors = g_hash_table_new(NULL, NULL); /* check to see if we have dialogue already running for this operation */ /* we key on the operation pointer, which is at least accurate enough for the operation type, although it could be on a different object. */ if (g_hash_table_lookup(active_errors, m->ops)) { g_warning("Error occurred while existing dialogue active:\n%s", camel_exception_get_description(&m->ex)); return; } </snip> Im working on to pass a hint, to differentiate the interactive and non-interactive refresh/check mail and may be pass-on the non-interactive search to status bar or so. Would appreciate any one's help to know, is some one seeing with head build or is that what im testing wrong?
srag, i still see this with today's 2.5.3 rpm snapshot. i'm still getting intrusive "error while fetching mail" popups.
Popups should also not appear during automatic mail-pickup if the mail-account is IMAP and Evo is not able to connect to the server at the first try. It should keep trying for x-times or for a time of x-minutes before a error message appears. I get "could not connect..." error messages about once per hour what kind of sucks.
we should retest this with the new network manager support in 2.5.4
marking bug 224288 as a duplicate, please DO read the comments at that bug because there are some interesting proposals.
*** Bug 224288 has been marked as a duplicate of this bug. ***
*** Bug 244655 has been marked as a duplicate of this bug. ***
*** Bug 319842 has been marked as a duplicate of this bug. ***
major UI change - punting target milestone to 2.7 due to ui freeze. not possible in 2.5 timeframe.
*** Bug 332942 has been marked as a duplicate of this bug. ***
*** Bug 343208 has been marked as a duplicate of this bug. ***
*** Bug 233980 has been marked as a duplicate of this bug. ***
*** Bug 207021 has been marked as a duplicate of this bug. ***
*** Bug 357946 has been marked as a duplicate of this bug. ***
*** Bug 360741 has been marked as a duplicate of this bug. ***
I have added a new mockup showing error handling in a very non-intrusive way in my newest mockup, see bug #360614 for more, I think this would be a great way of solving this bug, too.
IMHO, the way to go is to integrate Evo with the "Long Running Task Manager" Google SoC project: http://tw.apinc.org/weblog/2006/05/26
The targeted release has been missed - should this be assigned a new target?
whatever happened of evo just not doing anything online-related when network manager tells it there is no network connection?
I think actually that now (and for a while now) Evolution has the online/offline status button in the lower left corner. Pressing that takes Evolution offline - thus no more error messages. So I'm not even sure that this is still a bug that needs fixing.
This definitely *is* a bug that still needs fixing!!! The issue isn't predictable known offline handling. The issue is when a spurious interruption in service (name service, Internet access, pop server goes down, whatever) causes a single automatic email fetch to fail. In that case, there should be no error display dialog, but there is. This is a UI bug. The error display dialog should be displayed /only/ when a user-initiated fetch (i.e., the user clicked the Send/Receive button or pressed F9) fails. The reason is that spurious problems cause automatic fetches to fail frequently, and such failures don't require any action on the part of the user. They should stay below the user's radar. The way it is now, suppose the user leaves for an hour, leaving evolution running. Suppose that during that hour evolution performs 12 automatic fetches, the first one of which fails but the rest of which succeed, Evolution will have an intrusive dialog message waiting for the user when he returns, indicating a problem when there is none. That is crazy! Please do not remove this from the bug list.
@Dan: nobody plans to, and this one is on the list for the 2.14 release, but is complex and needs a lot of code rewriting.
*** Bug 478594 has been marked as a duplicate of this bug. ***
*** Bug 482615 has been marked as a duplicate of this bug. ***
*** Bug 485555 has been marked as a duplicate of this bug. ***
*** Bug 499029 has been marked as a duplicate of this bug. ***
OK, this bug has now been around for over 4 years unfixed (and I am using Evo for exactly one week now and reported a duplicate...) Just to add another example how useless these popup are. For me they come up because sometimes the IMAP server does reject ping attemps (for whatever reason). Usually Evolution will detect Mail anyway (maybe 10 minutes later but who really cares). And one other point - these popup also set a window manager hint so that windows come on or blink or whatever your window manager wants to do with them. This is really, really annoying!
*** Bug 398224 has been marked as a duplicate of this bug. ***
Please, please fix this bug. I have a similar issue where occasionally one of my IMAP email accounts isn't available for the automatic check. The error message / focus theft behavior leaves unwanted screen litter, interrupts my workflow a few times a day, and completely inconsistent with the quality I've come to expect from the GNOME environment. (It just happened again as I was typing this, had to retype the last sentence. Frustrating!)
initial support for fixing this issue has been implement in the unstable evolution development version 2.21.4, see http://blogs.gnome.org/sragavan/2007/12/18/annoying-popups-with-evolution-hmmno-more/ for some mockups. this will not be backported to former stable versions, like evolution 2.12 or 2.10. the next stable evolution release 2.22, announced for march 2008, will include these changes.
What about going more of the way I mocked up here: https://bugzilla.gnome.org/attachment.cgi?id=74331 Drawing all the actions in the status bar is problematic and does not scale very well. I explained a bit more in a comment of the blog post mentioned above.
michael, what exactly do you refer to in that screenshot? i'm against integrating the send&receive dialog into the normal mail view.
Well, as it looks right now, the new way of displaying these things is something like this in the status bar: |________||________||________| If there are more than three actions running at a time (for example, if you fetch mail from 5 accounts and send mail, too) only three get shown. If one task is completed, it will make room to display others. Is this correct? Well, the problems I have with this: a) The fact that only a limited number of tasks can be shown like this means that some probably never get shown because they are completed before there is a chance to display them. b) What happens if a user does not have the location bar enabled? Will there be no feedback at all in this case? If there are no mails, the user will probably think evolution is doing nothing. Also, if there are errors, the user will probably not novice. Forcing the status bar to be always visible would solve this, but I don't think it would be the best idea. What I proposed was not meant to be "moving the normal dialog into the main window", but to have a "message area". This could also be done as part of the status bar, but IMHO the way banshee does it works best: having a "message bar" for every kind of task (sending mail, receiving mail, errors... those three would do I think) and just show them when needed. So you would only have one "send" bar at a time etc. For integration into the status bar, I think you should do it this way: |_5_Tasks_running..._||_2_Errors..._| For more information you would click on either tasks or errors, which would pop up some details.
I think using Mathusalem (some kind of notification with progress bars for long-running tasks, see http://live.gnome.org/Mathusalem) for that would make much more sense.
Guys, keep in mind that this bug is for an intrusive error dialog that results from a *NON*-user-initiated action--in other words, a background task--and for which the failure condition is non-fatal and usually temporary. Simply not displaying a notification should really be an acceptable fix. If the outage (or anything that causes a scheduled mail fetch to fail) is longer-lasting and the user wonders why he's not getting mail, then he can click "Send/Receive" and he'll get the error notification dialog.
I think that there should be some sort of notification, but something like an attention icon that the user could click on to know what is going on. Afer all the user asked the mail to be checked. So he might need to know.
Yes, an icon--maybe a little exclamation or something down in the corner--that would suffice. Furthermore, it only makes sense to display such an icon when the latest attempt to fetch mail has failed. If one fails and the next one succeeds, then the icon (or whatever notification is presented) should go away.
Well, I was hoping for a solution that would also get rid of the send/receive dialog :( Having two different ways to show the same thing, even if user-triggered in the one case and automated in the other case does not seem to be a good idea.
I think it does make sense, since to a user they actually represent different usages. (Yeah, even though they both boil down to "getting email.") It's not at all unreasonable for a user to decide that she wants the background fetches to occur only once/hour, but then occasionally need it to fetch on command. Once that notion is accepted, then regardless of how the user-initiated send/receive activity is displayed (dialog, status bar, whatever), it makes sense to display an intrusive dialog when the user-initiated instance of the action fails but not when a background scheduled instance of the action fails.
>> it makes sense to display an intrusive dialog when the user-initiated >> instance of the action fails but not when a background scheduled >> instance of the action fails. I have to disagree. If a user sets the fetch interval to 5 minutes, he does so because he wants his mail asap. So, if there is an error, it does not matter if the task was started automatically. If this was the case, a user would probably not notice for some hours that his connection or mail server has problems.
(In reply to comment #71) > I have to disagree. If a user sets the fetch interval to 5 minutes, he does so > because he wants his mail asap. So, if there is an error, it does not matter if > the task was started automatically. If this was the case, a user would probably > not notice for some hours that his connection or mail server has problems. That's the purpose of the non-intrusive notification. The thing about a dialog is that it doesn't go away by itself. If the user is away (or busy in a different application) for 15 minutes and the fetch failed the first time but then succeeded the next time, there should definitely not be an error notification dialog waiting for him when he gets back--or popping up to interrupt his work. And, not to put too fine a point on it, but what the user (at least one user) wants in this regard is indicted by the fact that this is exactly what the original bug report was about.
(In reply to comment #69) > Well, I was hoping for a solution that would also get rid of the send/receive > dialog :( > This a bug 363481 IMHO.
>> That's the purpose of the non-intrusive notification. But it will not help at all if the evolution window is minimized. For that case there should be a notification bubble. One that is updated or even cleared (when the problem changes or is not present anymore)
I hope this is useful feedback, I do appreciate all of you working on this. As an end user, I really would like to have my email check every 10 - 15 minutes so that when I hit a break in my work and want to check email I don't have to hit refresh, and I know things are reasonably up-to-date. Having a little warning tag that might dissappear without me ever knowing in the corner, just in case, would be much nicer than any dialog box or bubble showing up outside the Evolution window. The thing to keep in mind is that most of us aren't running our own mail servers and would rather not be kept up to date on their status, especially when they aren't working right.
You should check Emmanuel Pacaud's proposal in #360614 (comment 7). He proposes a throbber to display an overall current transmission status, which includes error indication. A click on the throbber would display detailed information, the error indication would vanish once the problem disappears. I think that throbber could even replace the send/receive button. For people who want pop-ups those should be configurable. Maybe a first-time pop-up as Dave Malcolm proposed in comment #30 would ensure people won't miss the configuration option. Just to freeze the Network-manager-solves-this-bug discussion, I want to mention that many computers are always connected to a network, even when the internet connection is not available or the mail server is down for a minute. Also there are many configurations that work entirely without NetworkManager as it fails to be suitable for all setups, especially for computers with several network connections which may be connected at the same time.
------- Comment #72 from Dan Engel 2007-12-19 17:56 UTC ------- (In reply to comment #71) > > I have to disagree. If a user sets the fetch interval to 5 minutes, he does so > > because he wants his mail asap. So, if there is an error, it does not matter if > > the task was started automatically. If this was the case, a user would probably > > not notice for some hours that his connection or mail server has problems. > > That's the purpose of the non-intrusive notification. The thing about a dialog > is that it doesn't go away by itself. If the user is away (or busy in a > different application) for 15 minutes and the fetch failed the first time but > then succeeded the next time, there should definitely not be an error > notification dialog waiting for him when he gets back--or popping up to > interrupt his work. > > And, not to put too fine a point on it, but what the user (at least > one user) > wants in this regard is indicted by the fact that this is exactly what the > original bug report was about. I'm one of the may people that originally reported this bug - years ago. Dan is right, IMHO. Michael, I believe you're looking at this from the wrong perspective. All your suggestions run counter to what I believe is reasonable. Here are some more specifics from my perspective: (1) It's a specific bug that needs fixing, not a request for a general user interface change. (e.g. existence of send/receive dialog) (2) Normally, my system sits there and checks for mail every so often. (3) If there's a temporary glitch that recovers before I next use the machine, I don't need lots of dialog boxes telling me so. I'd prefer none, but could live with one. I would like to be able to actively choose to review a full connection history if I'm diagnosing though. (4) If there's a glitch that's still there when I use the machine, I'd like to know - either a temporary dialog, status bar, systray (n.b. must work with all window managers etc, I don't use a gnome desktop), whatever. (5) Sometimes, I want to request a mail download immediately. Perhaps I'm diagnosing or perhaps I'm on the phone to somebody who sends me something. (6) BTW, why would I ever minimise a mail client? That's what multiple desktops are for, IMHO. ------- Comment #73 from Hubert Figuiere 2007-12-19 18:21 UTC ------- (In reply to comment #69) > > Well, I was hoping for a solution that would also get rid of the send/receive > > dialog :( > > > This a bug 363481 IMHO. I think Michael's wrong - what he's suggesting is a feature change, not a fix for this bug. But I think 363481 is a different feature change and BTW the OP didn't ask for the dialog to be allowed behind anything - that would be a really bad idea, IMHO. He asked for the ability to minimise it!
>> (6) BTW, why would I ever minimise a mail client? >> That's what multiple desktops are for, IMHO. Sure you can have a desktop for every application, but how does this fix the problem that you won't see any error notification if you don't currently use that desktop? @Hubert: What I was originally hoping for was a way to sanely handle manual and automatic tasks the same way, not a "feature change". The tasks don't care if they are run because a timer says so or the user presses a button, I really don't see a reason why they should look differently. And right now, pressing send/receive shows both the old dialog and the bar at the bottom, which is quite redundant.
> Sure you can have a desktop for every application, but how does this fix the > problem that you won't see any error notification if you don't currently use > that desktop? It isn't a problem, that's why! If I'm not currently using that application/desktop *I don't care* whether the automatic mail fetch isn't working at that particular moment. *When I look at the mail application* is when I care about it! > @Hubert: What I was originally hoping for was a way to sanely handle manual and > automatic tasks the same way, not a "feature change". The tasks don't care if > they are run because a timer says so or the user presses a button, I really > don't see a reason why they should look differently. And right now, pressing > send/receive shows both the old dialog and the bar at the bottom, which is > quite redundant. It's blindingly obvious to me why they should be handled differently. One is a one-shot task that I just actively initiated and I am waiting for it to complete while the other is a permanently running background task. As I said before, I believe you're coming at this from entirely the wrong perspective. AFAICT from this comment, you're thinking about things from the application's perspective. What matters is the *users'* perspective!
Sorry, but what you are writing does not make any sense. Do I only care if a mail arrives when the mail window is open? If it is open, chances are good that I see the new mail right away. If I have the window minimized (or work on another desktop, same thing, really!) I care, too. What you are saying about application vs user perspective is just what you are voting for. As a user, I want to receive my mail and somehow notice that I got new mail WITHOUT *living* inside the application itself. Ideally I would never have to start evo myself but still have a part of it run as a daemon that checks for new mail and notifies me when some arrives or when there is any trouble. In case of errors, there could even be a preference like always informing the user, or silently keep trying for some time before notifying.
(In reply to comment #80) > What you are saying about application vs user perspective is just what you are > voting for. As a user, I want to receive my mail and somehow notice that I got > new mail WITHOUT *living* inside the application itself. Ideally I would never > have to start evo myself but still have a part of it run as a daemon that > checks for new mail and notifies me when some arrives or when there is any > trouble. In case of errors, there could even be a preference like always > informing the user, or silently keep trying for some time before notifying. For the purpose of new-mail-notification you have the notification area in the system tray, which is working good enough. People who don't want to be interrupted by mail have it turned off. The problem is a popup window that is frequently (in environments with unstable internet connection) annoying the user and he has _no_ chance of turning it off. I really don't understand the point of the discussion right here. Obviously there are people who like the error-dialog to pop up, others don't. Why not make it optional, as also previously stated. After that has happened we can still discuss better notification systems.
>> For the purpose of new-mail-notification you have the notification area >> in the system tray, which is working good enough. Right! But the same could also be used for error notification. Just a bubble that pops up in the corner after x (configurable) failed tries. Perhaps only show the bubble if the mail window is not currently maximized and on the same workspace (because if it is, you could see the error elsewhere) >> The problem is a popup window that is frequently (in environments with >> unstable internet connection) annoying the user and he has _no_ chance of >> turning it off. Yes. But as far as I can see the current design just "hides" the errors in the status bar. So for people with reasonably stable connections, who were not seeing error dialogs very often, now they don't see them anymore. And this is what I regard as a regression. Don't get me wrong, I don't want to be spammed with error popups, but if there are errors that require user interaction or scheduled things fail for a longer period of time, I want to know without going into the app and check myself.
> Sorry, but what you are writing does not make any sense. Do I only care if a > mail arrives when the mail window is open? If it is open, chances are good that > I see the new mail right away. If I have the window minimized (or work on > another desktop, same thing, really!) I care, too. Those are two very different cases. If I'm just looking at my mailer, I don't care if it's currently retrieving mail or whatever. But if I press "send/receive", maybe I'm waiting for an important mail or something, and I want to know when the operation is finished, to be sure that everything I see is what I got. Currently Evo acts as it should, but the fact that it opens a separate dialog is really too intrusive. There should only be a little something in the main windows (the several mockups I already saw are all quite good) which can give a quick progress indication, and can be clicked somewhere to show more if needs be.
After reflexion, it should be as automatic as possible. I.e. the operation starts, and there's just an icon or something tiny indicating that fact. But if the operation is slow (e.g. after 3 second it's still <50% completed) then a more complete status indicator, complete with named progress bars should appear somewhere (but please not in a full new window).
Sorry but since I get a mail notification for every comment in this pointless discussion you are starting to piss me off. I really appreciate the work done to fix the problem with the annoying error message popups. Thanks god that has been fixed at last. At this point I like to apeal the authors of this fine software to not change anything with the new error handling! Espacially DON'T make it optional. Software is often filled with useless optional stuff only some nerds use. And if someone isn't capable of having a look in the protocol - it's his own problem and he may go to hell...
I vote in the same direction as Andre Janssen. The currently proposed (and implemented?) behavior is very well thought out. Let this bug rest in *pieces*. Don't make it an option, Evolution's preferences dialog ressembles kcontrol enough already! +1 for the "I don't CARE if evo chokes on mail in the backround, I do *not* want my work to be interrupted!"
This bug is obsolete and can be closed as resolved.
right :) thanks again srini for fixing this! once again linking to what will be included in Evolution 2.22, released in march 2008: http://blogs.gnome.org/sragavan/2007/12/18/annoying-popups-with-evolution-hmmno-more/
*** Bug 410228 has been marked as a duplicate of this bug. ***
*** Bug 517686 has been marked as a duplicate of this bug. ***
*** Bug 520488 has been marked as a duplicate of this bug. ***