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

Reply via email to