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 <[EMAIL PROTECTED]> _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
