On Tue, 2011-05-03 at 18:04 +0200, Patrick Ohly wrote: > I was hoping to avoid this with more recent EDS, the local file backend > and simply calling e_cal_remove_object_with_mod() regardless whether it > has an rid or not. But it turns out that > e_cal_remove_object_with_mod(rid="") simply calls the removeObject D-Bus > method with an empty string for the rid, just like e_cal_remove_object() > does, and thus all events sharing the same UID get deleted. > > rid=NULL doesn't make any difference. > > What is the intended semantic of e_cal_remove_object_with_mod()? If "rid > empty or NULL, then remove only parent"?
Hi, using NULL or an empty string for 'rid' is equivalent. It's quite hard to pass NULL strings over DBus, so NULL is changed to an empty string anyway, and on the server-side it is changed to NULL, though each backend checks for "NULL or empty string" too. I would expect that with CALOBJ_MOD_THIS it may remove only exact component, for uid + NULL-rid the master object (which implies also all generated instances) and keep all detached instances, though this operation doesn't seem to have much sense to me. The problem is that each backend has its own implementation of such operation (also note that groupwise backend has no master object (it tells it in capabilities)) and for example file backend behaves with rid=NULL mod=CALOBJ_MOD_THIS the same like with mod=CALOBJ_MOD_ALL, thus it drops also detached instances. In other words, the 'mod' may make the difference, from my point of view. > 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've no idea on this. I'm sorry. Bye, Milan _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers