Hello Ross!

Can you perhaps comment? You wrote the TODO items below...

On Di, 2011-05-03 at 18:04 +0200, Patrick Ohly wrote:
> 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 found this in e-data-cal-view.c notify_remove():

280             /* TODO: store ECalComponentId instead of just uid*/
281             uid = g_strdup (id->uid);
282             g_array_append_val (priv->removes, uid);

In other words, removes always come without rid, even if the actual
event that was removed was not the parent but a detached recurrence.

There's another, similar TODO in send_pending_removes():

192             /* TODO: send ECalComponentIds as a list of pairs */
193             e_gdbus_cal_view_emit_objects_removed (view->priv->gdbus_object,
(const gchar * const *) priv->removes->data);

And sure enough, the actual D-Bus API uses an array of strings instead
of an array of string pairs.

I can fix these TODOs. Any objections or concerns?

It'll lead to a change of the D-Bus API. For "master" that shouldn't be
a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I
guess we have to bite the bullet and maintain a MeeGo version with a
different API than regular 2.32.x.

One more question about e_cal_backend_notify_object_removed(): it takes
iCalendar 2.0 object strings as parameter in addition to the id. If both
are set, it acts like "object_updated". If the new "object" is NULL, it
checks whether the "old_object" matches the view. Is that really
necessary? There is a second check whether the ID is in the view in

701             for (l = ids; l; l = l->next) {
702                     ECalComponentId *id = l->data;
703                     if (g_hash_table_lookup (priv->ids, id))
704                         notify_remove (view, id);
705             }

At least that is my understanding. So is it safe to pass only the ID and
old_object = object = NULL?

Bye, Patrick Ohly

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to