Re: [Evolution-hackers] NO_THISANDFUTURE/THISANDPRIOR and file backend

[Andrew McMillan]

On Thu, 2011-05-12 at 13:58 +0200, Patrick Ohly wrote:
> Hello!
> 
> Why does the file backend claim that it doesn't support
> CAL_STATIC_CAPABILITY_NO_THISANDFUTURE and
> CAL_STATIC_CAPABILITY_NO_THISANDPRIOR?
> 
> There is code for these in remove_object_instance_cb(),
> e_cal_backend_file_modify_object() and
> e_cal_backend_file_remove_object(). Is all of that dead code that was
> never used and tested?
> 
> I don't need this feature, I just wonder.

Hi Patrick,

I have no idea either, but if anyone is thinking of changing it I note
that THISANDPRIOR is deprecated as of RFC5545.

Cheers,
Andrew.
-- 

http://andrew.mcmillan.net.nz/ Porirua, New Zealand
Twitter: _karora  Phone: +64(272)DEBIAN
 How many things I can do without! -- Socrates




signature.asc
Description: This is a digitally signed message part
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] NO_THISANDFUTURE/THISANDPRIOR and file backend

[Patrick Ohly]

Hello!

Why does the file backend claim that it doesn't support
CAL_STATIC_CAPABILITY_NO_THISANDFUTURE and
CAL_STATIC_CAPABILITY_NO_THISANDPRIOR?

There is code for these in remove_object_instance_cb(),
e_cal_backend_file_modify_object() and
e_cal_backend_file_remove_object(). Is all of that dead code that was
never used and tested?

I don't need this feature, I just wonder.

-- 
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

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

[Patrick Ohly]

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