Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
- From: Patrick Ohly <patrick ohly gmx de>
- To: Milan Crha <mcrha redhat com>
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
- Date: Wed, 11 May 2011 08:21:17 +0200
On Di, 2011-05-10 at 10:23 +0200, Milan Crha wrote:
> On Wed, 2011-05-04 at 17:31 +0200, Patrick Ohly wrote:
> > On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote:
> > > On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
> > > > 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,
> > >
> > > Okay, then we agree on the desired semantic.
> >
> > I ran into another oddity: suppose there is a recurring event without
> > exceptions and a detached recurrence gets added. The libecal API does
> > not support undoing that operation.
> > ...
>
> Hi,
> it sounds like you might find useful an addition of a reverse function
> for
> gboolean e_cal_client_get_object_sync (
> ECalClient *client,
> const gchar *uid, const gchar *rid,
> icalcomponent **icalcomp,
> GCancellable *cancellable, GError **error);
> which can return either one component, or a VCALENDAR component.
>
> I'm thinking of something like:
> e_cal_client_replace_object (..., const gchar *uid,
> /* const */ icalcomponent *icalcomp, ...);
> Note it doesn't take the 'rid' parameter as the get_object function.
Yes, there might be cases where that is better than the current API. But
I see it as complementary to enhancing the existing, single-event
focused APIs.
--
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]