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
e_data_cal_view_notify_objects_removed():
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
--
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
