Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?



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 Ohly gmx de
http://www.estamos.de/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]