On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote: > On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote: > > I would expect that with CALOBJ_MOD_THIS it may remove only exact > > component, for uid + NULL-rid the master object (which implies also all > > generated instances) and keep all detached instances, > > Okay, then we agree on the desired semantic.
I ran into another oddity: suppose there is a recurring event without exceptions and a detached recurrence gets added. The libecal API does not support undoing that operation. e_cal_remove_object_with_mod(rid=<datetime>, CALOBJ_MOD_THIS) will remove the recurrence but it will *also* add an EXDATE for that recurrence. So the calendar is not in the same state as it was before adding the detached recurrence. This behavior may make sense for a UI ("remove this recurrence" implies adding the EXDATE), but not for syncing. May I add a CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY mode? > If a backend doesn't support the semantic, then there's not much that > can be done. But the file backend should be able to to handle it, > therefore I consider it a bug that it removes all instances in this > case. > > I'll look into fixing this. I have a patch ready. Will continue to test and send when the rest also passes my tests. > > > I also wonder about the "objects-removed" signal in ECalView. If there > > > are two events, one with RRULE and one with RECURRENCE-RULE, and both > > > get removed, should there be two entries in "objects-removed"? > > > > I've no idea on this. I'm sorry. > > First things first ;-) Let me fix the removal, then look into this > problem here. ECalView is indeed odd. My initial understanding is that the file backend will never send information about removed detached recurrences, so rid is always empty. What I get instead when removing a detached recurrence is a "master modified" with EXDATE set. I suspect that the Evolution UI uses that to remove the corresponding detached recurrence. Does anyone know whether that is the case? If I introduce the CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY, then EXDATE won't be set and a real "object-removed" with rid set will be needed. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers