Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
- From: Patrick Ohly <patrick ohly gmx de>
- To: Evolution Hackers <evolution-hackers gnome org>
- Subject: Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
- Date: Wed, 04 May 2011 17:31:17 +0200
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 Ohly gmx de
http://www.estamos.de/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]