GNOME Bugzilla – Bug 609646
Correct factory close confuses evolution
Last modified: 2013-09-14 16:53:38 UTC
Consider these steps: a) Run evolution in mailer - the only applications running are evolution and e-addressbook-factory because no alarm notify is started and no calendar was opened yet b) select a meeting invitation mail - the e-calendar-factory has been run c) select the previous mail, some non-meeting invite d) wait 15 seconds - actually 10 is enough, because moving out from the meeting invite makes e-calendar-factory think no-one is needing it any more, thus it is closing itself after 10 seconds e) select the meeting invite mail again Watch the console with couple runtime warnings about unhappy Evolution loosing connection to the process on dbus. It should notify the proper close and make the global dbus session NULL or something, and run the factory again, if needed.
Note that evolution-alarm-notify is an autostart program now, and will start with your desktop session (in a GNOME 2.29 environment) before you even launch Evolution.
Yup, I know, and not running it makes this much easier to reproduce, because for example e-addressbook-factory is not closed because some EBooks are left opened on picture or load images lookup (which is OK).
Created attachment 153570 [details] [review] eds patch for evolution-data-server; Seems simple, though got me some time to investigate this. I even didn't notice that it's somehow done on EBook, but not on ECal, only when I had ECal done. I changed it on EBook as well, as I believe it's the correct way how to unset factory_proxy pointer on closing of the "remote" process.
Created commit 37db648 in eds master (2.29.91+)