Re: [Evolution-hackers] recurrences work plan

[Rodrigo Moya <rodrigo novell com>]

On Tue, 2004-10-26 at 13:09 +0200, Rodrigo Moya wrote:
> Hi
> 
> Some time before 2.0 I created a branch for working on a better support
> for detached recurrences. Some of that work was merged to HEAD time
> before 2.0, but some of it was left because it was missing some details.
> 
> This is a description of that work left for post-2.0.
> 
> * when notifying a removal, backends need to pass both the old_object
> and the new object, which is NULL in all cases except when removing an
> individual instance. In that case, e_cal_backend_notify_object_removed
> notifies an update instead of a removal. This is the only change needed
> in the backends, which need to pass an extra argument to
> e_c_b_notify_object_removed.
> 
> * the views don't generate the instances themselves anymore, it's the
> model job now, so the views just display the events that are in the
> model. When generating instances in the model, we add the RECURRENCE-ID
> property to them, so that the GUI can deal with the individual instances
> correctly.
> 
> I have all this now working, with a few small details missing, so should
> be ready for merging to HEAD pretty soon.

Forgot to mention another thing I was going to do on this branch, which
is adding a e_cal_get_objects_with_uid call to avoid calling
get_object_list for getting master recurring events and all its detached
recurrences (which is bug #59904). Thus, backends will return a
VCALENDAR when there is more than one event with the given UID, and the
e_cal_ API will process that internally so that we keep the same API as
in 2.0.
-- 
Rodrigo Moya <rodrigo novell com>