Yeah, this is fairly irritating.

*** Bug 300432 has been marked as a duplicate of this bug. ***

retargetting from 1.3 to 1.5 to get rid of that busted milestones (as discussed
with harish on irc)

Would love to see this one hit EDS 1.6.  I have like 10 calendar sources, and when EDS crashes, you get dialogs for each one and they uncheck one-by-one and then when you go back into Evoluton you have to re-check them all.

Two things should change in my view:

1) If they have to uncheck, have ONE dialog appear and then uncheck them all at once.

2) When you re-enter Evolution, the ones that were checked should be checked as they were before.  It seems like when they are being unchecked, that setting is being stored somewhere as something that I have selected.

ping?  Harish said this was close.

I received a patch for this but did not approve it - as it failed to handle some scenarios and has serious performance implications. We might not be able to address this situation without a not-so-minor-design change - which can probably go into 2.7 onwards - not 2.6.

removing old target milestone, retargetting to 1.7.

I know this is the issue from hell, but it's causing a lot of support problems for us.  EDS crashes a few times a week for most users.  When that happens, all of their calendars are getting unchecked.  They then call our support group to find out why all of their appointments are "missing".  The concept of checking/unchecking sources is beyond their understanding.

Moving forward since nothing appears to have been changed here.

Created attachment 97058 [details] [review]
proposed evo patch

for evolution;

It's a bit longer, but only because of same thing for three times.

Chen, can you review this for 2.21.2?

Chen told me on the IRC yesterday that he was poking at this patch and had some ideas to get it worked into 2.21.  I also have requested that this be back ported to 2.6 on SLED.  This is a *huge* UI issue for our users.  Some of the users have around 20 calendars (mostly webcals) and when they uncheck, it's not pleasant. :)

Cool. 

Chen can you plan this for 2.21.3?

Once EDS crashes, the calendars are restored once evolution is restarted. One of the annoying issues in the same is area is error dialogs appearing for every calendar, tasks & memos. The better approach would be to display a single error message in status bar as it does not make much sense to the user and reload all the calendars automatically based on the selected calendars. If the calendar crashes again after reloading, we can have three tries atmost and unselect all the calendars after that providing a proper status message. IMHO, suggesting users to restart evolution may not be a good solution.


With the current patch, consider the case if the user does not restart evolution when EDS crashes, and choses to change the selection of the calendars. On restarting evolution, the latest selection (consider both selected/unselected calendars) is not maintained. The users do not have an indication that they have to restart evolution once EDS has restarted to maintain their selected calendars.

I feel strongly that the calendar must *never* uncheck.  If EDS will not restart, Evolution is not running correctly and should be restarted.  In our case using the GroupWise backend, it's worthless to try and continue the Evolution session.

If users of other backends have a pressing need for Evolution to continue to run, then I suggest that you create a new gconf key that contains the runtime calendars in use.  

So it would work like this:

1) Evolution starts
2) Evolution sets gconf key calendars_enabled to a string which contains all enabled calendars.
3) Evolution-data-server uses that key instead of the ones enabled in the UI
4) If evolution-data-server crashes, try and restart 3 times
5) upon failure, calendars_enabled is set to null

What would happen then is that the next time you restart Evolution, it would be configured as you left.

Unchecking calendars is changing user settings, and should never be done.  This greatly frustrates the users and causes a lot of support calls.  Upon restart, they have no idea how to re-enable them and where to find them.  Many have never clicked into Task View even once and only see it from Calendar View and don't know how to enable Tasks in that view.

(In reply to comment #16)
> I feel strongly that the calendar must *never* uncheck.  If EDS will not
> restart, Evolution is not running correctly and should be restarted.  In our
> case using the GroupWise backend, it's worthless to try and continue the
> Evolution session.

I don't think so since only calendar/addressbook uses EDS. Mailer need not be restarted. I guess there would some fixes required to client the old client (ECal) data properly which needs to be fixed. IMHO restarting evolution or reloading calendars after removing the old connections should work the same way.

> 
> If users of other backends have a pressing need for Evolution to continue to
> run, then I suggest that you create a new gconf key that contains the runtime
> calendars in use.  
I am not thinking about any specific backends here since the problem is common to all.

> 
> So it would work like this:
> 
> 1) Evolution starts
> 2) Evolution sets gconf key calendars_enabled to a string which contains all
> enabled calendars.
> 3) Evolution-data-server uses that key instead of the ones enabled in the UI
> 4) If evolution-data-server crashes, try and restart 3 times
> 5) upon failure, calendars_enabled is set to null
> 

> What would happen then is that the next time you restart Evolution, it would be
> configured as you left.
EDS cannot depend on the gconf keys for enabled calendars since many other apps can use EDS for fetching contents.

> 
> Unchecking calendars is changing user settings, and should never be done.  This
> greatly frustrates the users and causes a lot of support calls.  Upon restart,
> they have no idea how to re-enable them and where to find them.  Many have
> never clicked into Task View even once and only see it from Calendar View and
> don't know how to enable Tasks in that view.

Most often the crashers are not consistent ones. So reloading the calendar/tasks automatically after providing the proper message in the status bar should work fine in just one try. But if in case it happens consistently, we should anyway have to un-select all the calendars/tasks since we will not be able find which calendar/tasks is causing the crash.

mcrha, srag, what do you think ?

(In reply to comment #15)
> With the current patch, consider the case if the user does not restart
> evolution when EDS crashes, and choses to change the selection of the
> calendars. On restarting evolution, the latest selection (consider both
> selected/unselected calendars) is not maintained. The users do not have an
> indication that they have to restart evolution once EDS has restarted to
> maintain their selected calendars.
 
Chen, I think this is not truth. If I recall correctly, then the component itself tracks list of died sources, which has been active. So every time it stores the change, these died sources are added as checked, even they are not, actually. And my point is, when you try to check/uncheck the source, before restarting, then it is removed from died sources, thus it stores actual state. I did it in this way, I think.

If you move the error messages to status bar, then user will not be able to see it, thus will not know there is an issue and he/she should restart evo to let it work. (I do not know why it suggest to restart it, but seems to me like working/good idea, which solves most issues. Even not all, you've right.

(In reply to comment #17)
I see a big difference between calendar and mailer component, the most significant difference is that the calendar is "talking" to eds through bonobo (at the moment), but mailer just links eds functions/libs, which is a big difference, from my point of view. It makes sense that the mailer works even witout restart of eds, because it actually doesn't "talk" to it (to the process), it just links to it directly. It seems to me like that, at least.

You've right that eds should not store anything in gconf, it's the part of user interface, in this case Evolution. 

Just my thoughts, maybe I'm wrong with some of them. Let srag say what he thinks.

Milan/Chen, I'm wearing a user's hat here. Ideally, if EDS crashed, it shouldn't be 10 dialog for 10 calendars I have. I know that it is possible to load calendars automatically by checking it again (If not, lets fix that). When it is so, why showing dialogs and asking him to uncheck it. Have a backend-died function which restarts eds or gets a new connections with eds and works transparently. You can log a error that EDS died. Unless the user sees it, he doesn't have to know that

Only in case of consistent eds-crash-on restart may be 2/3rd attempt prompt one error that EDS crashes consistently and ask for a action or something else.

Milan, Mailer also speaks to EDS through bonobo only as calendar. (Mailer uses itip-formatter/ecal to i/f with eds for accept/decline meetings etc). Autocompletion uses EBook to speak to EDS again bonobo is the underlying thing. 


No gconf things really IMO

OK, it's much harder, but better probably. Unless you need to use this workaround until better solution?

It speaks to eds only because of request for ECal/EBook, I thought about it.
What I wanted to say was that the Mailer component uses amount of things from eds without bonobo, like camel things and so on, to which doesn't matter if eds died or not. (I think, at least).

Created attachment 102394 [details] [review]
proposed evo patch ][

for evolution;

This is updated patch to actual trunk and contains some of the things mentioned above (the core is same as before, I just changed some little things).
Here are my notes:

a) I added new files 'calendar/gui/cal-utils.[hc]' to sources, with the intend to have a place where to put shared things between calendar components, some utility functions. I know about misc.c and comp-util.c, but none of these fits to me. I am going to move some duplicated code from sources here, if approved.

b) It works now like before, if the backend die, then the source is unchecked, the message about died backend is shown, and died source is tracked in the component. If such calendar is reopened by user, then it is also removed from died sources, thus the exit will save the actual state defined by user (if he check it and after some time uncheck it, then the source will be kept unchecked next start). The new thing here is that the message about died backend is shown for each component only once (I think it's better to show calendar died, tasks died, memos died, than only one message, because those are different components.)

c) The attempt of trying to reopen calendar after backend dies automatically doesn't seem to me as possible, because during my tests, when I kill eds with 'kill -QUIT xxx' (which I think is almost correct end of the application), I'm not able to recheck the local calendar, it shows on the console:
calendar-gui-WARNING **: Unable to load the calendar A CORBA exception has occurred
but next start of evo is just fine.

And that's all. Let me know your comments, thoughts, advices...

Milan, I would like not to take this solution. I wish it should be all automatic. Chen is gonna rewrite a few bits of calendar with threadpools/etc. I think the redesign bits should enable us or make it automatic. The last resort is this soln IMO.

Sure Srag, just let me know if something changes.

*** Bug 326154 has been marked as a duplicate of this bug. ***

This might be finally addressed with 2.32.0+ (maybe 2.30.0+), I do not recall precisely. When the calendar factory crashes then there is no calendar unchecked. I do not know whether Matt did it intentionally, but it's there.

I'm buying a lottery ticket tonight! :D