On 12 May 2011 11:44, Patrick Ohly <patrick.o...@gmx.de> wrote: > Can you perhaps comment? You wrote the TODO items below... [snip] > I can fix these TODOs. Any objections or concerns?
None whatsoever, those are embarrassingly leftin from the very early porting where large chunks of code were copied from the contacts code that just had an UID... > 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. I've always said that the DBus interface isn't a stable API and shouldn't be trusted to remain constant. If nobody else documented that the DBus interface is stable then we shouldn't worry too much. As a DBus API designed to be used by anything other than libebook/libecal it's pretty dire. > 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 afe to pass only the ID and > old_object = object = NULL? The logic there is probably mostly identical to the original logic in the ORBit port, and the calendar side isn't something I'm knowledgeable in... That said the view checking seems to have been to ensure that you don't get remove events for items you've never had. As to the semantics, I'd say if they are not documented make them reasonable and document them. :) Ross _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers