On Fr, 2011-05-13 at 15:34 +0100, Patrick Ohly wrote: > The implementation is good enough to read and write simple events with > time zone information. Detached recurrences are not working yet. I have > code ready for it, but because of issues in the libecal API and > implementation, the result doesn't work yet. For the curious, here's > where I am discussing this: > http://mail.gnome.org/archives/evolution-hackers/2011-May/msg00001.html
I have finished patching EDS, review of the result pending. If anyone wants to try it out, the "evolution-data-server" in the "eds" OBS project has the necessary patches applied: http://build.meego.com/package/show?package=evolution-data-server&project=eds I pushed the modified KCal-EDS. I see one issue with it when running the "testchanges" test under valgrind: ==3277== Invalid read of size 4 ==3277== at 0x8062F37: eKCalImpl::EDSStorage::calendarIncidenceDeleted(QSharedPointer<KCalCore::Incidence> const&) (qglobal.h:2064) ==3277== by 0x6B62A02: KCalCore::Calendar::notifyIncidenceDeleted(QSharedPointer<KCalCore::Incidence> const&) (in /usr/lib/libkcalcoren.so.4.1.18) ==3277== by 0x6C23BAC: KCalCore::MemoryCalendar::deleteIncidence(QSharedPointer<KCalCore::Incidence> const&) (in /usr/lib/libkcalcoren.so.4.1.18) ==3277== by 0x805F682: eKCalImpl::EDSStorage::objectsRemoved(_ECalView*, _GList*, eKCalImpl::EDSStorage*) (eds-storage.cpp:356) ==3277== by 0x8DB1941: g_cclosure_marshal_VOID__POINTER (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DA454E: g_closure_invoke (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DAD3EA: ??? (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DBDC29: g_signal_emit_valist (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DBDE52: g_signal_emit (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x801D19D: objects_removed_cb (e-cal-view.c:159) ==3277== by 0x8DB18AD: g_cclosure_marshal_VOID__BOXED (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DA454E: g_closure_invoke (in /lib/libgobject-2.0.so.0.2800.6) ==3277== Address 0xcd86af8 is 24 bytes inside a block of size 32 free'd ==3277== at 0x48CB8DD: operator delete(void*) (vg_replace_malloc.c:387) ==3277== by 0x8062CB7: eKCalImpl::EDSStorage::calendarIncidenceDeleted(QSharedPointer<KCalCore::Incidence> const&) (new_allocator.h:95) ==3277== by 0x6B62A02: KCalCore::Calendar::notifyIncidenceDeleted(QSharedPointer<KCalCore::Incidence> const&) (in /usr/lib/libkcalcoren.so.4.1.18) ==3277== by 0x6C23BAC: KCalCore::MemoryCalendar::deleteIncidence(QSharedPointer<KCalCore::Incidence> const&) (in /usr/lib/libkcalcoren.so.4.1.18) ==3277== by 0x805F682: eKCalImpl::EDSStorage::objectsRemoved(_ECalView*, _GList*, eKCalImpl::EDSStorage*) (eds-storage.cpp:356) ==3277== by 0x8DB1941: g_cclosure_marshal_VOID__POINTER (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DA454E: g_closure_invoke (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DAD3EA: ??? (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DBDC29: g_signal_emit_valist (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x8DBDE52: g_signal_emit (in /lib/libgobject-2.0.so.0.2800.6) ==3277== by 0x801D19D: objects_removed_cb (e-cal-view.c:159) ==3277== by 0x8DB18AD: g_cclosure_marshal_VOID__BOXED (in /lib/libgobject-2.0.so.0.2800.6) I'm not sure whether this is a bug in KCal-EDS. At first glance it seems to happen all inside KCalCore, while KCal-EDS still has a valid KCalCore::Incidence::Ptr (= QSharedDataPointer) inside its "KCalCore::Incidence::List incidences" list. Chris, perhaps you can have a look? I'll be away for two weeks starting this Friday and still need to wrap up some other stuff. Further todos: * package it in OBS ("eds" project, for a start) * extend API as needed by Sirisha * implement the idle write back of changes: the idea was to call save() regularly when the app is idle -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
