Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
> I'll do it as [\n] so that entries without an rid continue to
> look exactly like the current ones.
Looks good. I ran my KCal-EDS test program which adds, modifies and
removes events, including parent and child (= detached recurrence) in
various orders.
I am now seeing all ECalView signals that I expect and need.
I also ran Evolution in parallel to the test and saw it react to all
signals, but not quite as I would have liked.
Evolution seems to interpret uid + empty rid as "all recurrences
removed", which IMHO is wrong. It should mean "parent removed", because
otherwise there is no way of expressing that change.
For "child removed, parent not updated (= no EXDATE added)" I would
expect Evolution to show the original, unmodified recurrence again.
Instead it only removes the recurrence (as if EXDATE had been added).
I consider this an Evolution bug which can and should be fixed
separately. Please understand that it is currently lower priority for
me, my main goal has to be to get EDS working as intended in EKCal-EDS,
without Evolution.
Please have a look at the attached patch series. They were tested with
the gnome-2-32 branch. Except for the very last one, all apply to
"master". Does this look okay? May I submit to "master" (after fixing
the last patch), gnome-3-0 and gnome-2-32?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
>From 2e128c63a4a9dd64a3a327262498deb869a119f7 Mon Sep 17 00:00:00 2001
From: Patrick Ohly
Date: Wed, 11 May 2011 16:59:51 +0200
Subject: [PATCH 1/8] calendar file backend: support removing parent event with CALOBJ_MOD_THIS
It was possible to create a meeting series with just a detached event
(RECURRENCE-ID set) by importing a meeting invitation for that single
recurrence. It was not possible to arrive at that same state after
adding the parent event (the one with the RRULE) because
e_cal_remove_object_with_mod() removed all instances for
CALOBJ_MOD_THIS and empty rid.
This contradicts the intended semantic of e_cal_remove_object_with_mod():
"By using a combination of the @uid, @rid and @mod
arguments, you can remove specific instances. If what you want
is to remove all instances, use e_cal_remove_object instead."
This patch implements the desired semantic:
- e_cal_backend_file_remove_object(CALOBJ_MOD_THIS) now always
calls remove_instance().
- remove_instance() was extended to also work for the parent
event.
- That call removes the complete object if nothing is left
after removing the instance. This case must be handled by
the caller. The return value is the original object (if
it still exists) and NULL if not.
- Because the uid pointer into the object may become invalid
as part of the removal, a more permanent pointer has to
be provided by the caller.
---
calendar/backends/file/e-cal-backend-file.c | 134 ++-
1 files changed, 88 insertions(+), 46 deletions(-)
diff --git a/calendar/backends/file/e-cal-backend-file.c b/calendar/backends/file/e-cal-backend-file.c
index 33bab50..7a8c450 100644
--- a/calendar/backends/file/e-cal-backend-file.c
+++ b/calendar/backends/file/e-cal-backend-file.c
@@ -2629,47 +2629,94 @@ e_cal_backend_file_modify_object (ECalBackendSync *backend, EDataCal *cal, const
g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
}
-static void
-remove_instance (ECalBackendFile *cbfile, ECalBackendFileObject *obj_data, const gchar *rid)
+/**
+ * Remove one and only one instance. The object may be empty
+ * afterwards, in which case it will be removed completely.
+ *
+ * @uidpointer to UID which must remain valid even if the object gets
+ * removed
+ * @ridNULL, "", or non-empty string when manipulating a specific recurrence;
+ * also must remain valid
+ * @return modified object or NULL if it got removed
+ */
+static ECalBackendFileObject *
+remove_instance (ECalBackendFile *cbfile, ECalBackendFileObject *obj_data, const gchar *uid, const gchar *rid)
{
gchar *hash_rid;
ECalComponent *comp;
struct icaltimetype current;
- if (!rid || !*rid)
- return;
+ /* only check for non-NULL below, empty string is detected here */
+ if (rid && !*rid)
+ rid = NULL;
- if (g_hash_table_lookup_extended (obj_data->recurrences, rid, (gpointer *)&hash_rid, (gpointer *)&comp)) {
- /* remove the component from our data */
+ if (rid) {
+ /* remove recurrence */
+ if (g_hash_table_lookup_extended (obj_data->recurrences, rid,
+ (gpointer *)&hash_rid, (gpointer *)&comp)) {
+ /* remove the component from our data */
+ icalcomponent_remove_component (cbfile->priv->icalcomp,
+ e_cal_component_get_icalcomponent (comp));
+ cbfile->priv->comp = g_list_remove (cbfile->priv->comp, comp);
+ obj_data->recurrences_list = g_list_remove (obj_data->recurrences_list, comp);
+ g_hash_table_remove (obj_data->recurrences, rid);
+ } else {
+ /* not an error, only add EXDATE */
+ }
+
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Do, 2011-05-12 at 13:17 +0200, Milan Crha wrote: > On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote: > > 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. > > ... > > 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. > > Hi, > I noticed it too, recently (at the beginning of this week, actually). > I suggest to not change the D-Bus API, rather encode the string pair > into the string, like "uid\nrid". I was planning to do so in the > master branch, but didn't do that yet. That's still a D-Bus API change: a libecal which receives a UID entry in that format won't know what to do with it. But it'll be easier to implement that way, so I'll give it a try first. I'll do it as [\n] so that entries without an rid continue to look exactly like the current ones. -- 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?
On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote:
> 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.
> ...
> 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.
Hi,
I noticed it too, recently (at the beginning of this week, actually).
I suggest to not change the D-Bus API, rather encode the string pair
into the string, like "uid\nrid". I was planning to do so in the master
branch, but didn't do that yet.
> 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?
You can pass both NULL if the old_object was completely removed. The
call if the object matches the view was kept there in time when the test
for "!old_object" was added. I do not recall exact circumstances, but I
think there was some rationale why it is so, though looking at it the
call of e_data_cal_view_object_matches() in
e_cal_backend_notify_object_removed() really seems unnecessary. Maybe it
was because of no expectations on the behaviour of
e_data_cal_view_notify_objects_removed_1().
Hope that helps a bit,
Milan
___
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?
On 13 May 2011 16:11, Patrick Ohly wrote: > Did the previous code transmit UID+RECURRENCE-ID? I am wondering why > Evolution manages to keep views properly in sync despite the lack of the > RECURRENCE-ID - and what'll happen when it starts receiving them. > > I guess I'll find out... I can't recall, sorry. Time to get a checkout from before the DBus merge... 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
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Fr, 2011-05-13 at 12:48 +0100, Ross Burton wrote: > On 12 May 2011 11:44, Patrick Ohly 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... Did the previous code transmit UID+RECURRENCE-ID? I am wondering why Evolution manages to keep views properly in sync despite the lack of the RECURRENCE-ID - and what'll happen when it starts receiving them. I guess I'll find out... -- 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?
On Fri, 2011-05-13 at 12:48 +0100, Ross Burton wrote: > On 12 May 2011 11:44, Patrick Ohly wrote: > > 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. It's fine to change the D-Bus API as needed, but remember to bump the version number in the bus name. I only recently added version numbers after the whole 2.30 -> 2.32 upgrade debacle, so we're still at: org.gnome.evolution.dataserver.AddressBook0 org.gnome.evolution.dataserver.Calendar0 The bus names are defined in evolution-data-server/configure.ac. This avoids the problem of users upgrading a client package like Evolution while the older D-Bus services continue running. If the D-Bus interface changed, now suddenly the client can't talk to the services correctly anymore. That's what caused all the problems with local:// ESource URIs in 2.32. ___ 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?
On 12 May 2011 11:44, Patrick Ohly 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
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.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?
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.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?
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. Its meaning would be "drop whatever you have stored for the component of the given uid and use content of given icalcomp instead", which could be either single component or a VCALENDAR with a list of detached components. There might be some checking that the uid matches uids stored in the icalcomp, but that's a minor thing. Just an idea. Bye, Milan ___ 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?
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.
e_cal_remove_object_with_mod(rid=, CALOBJ_MOD_THIS) will
remove the recurrence but it will *also* add an EXDATE for that
recurrence. So the calendar is not in the same state as it was before
adding the detached recurrence.
This behavior may make sense for a UI ("remove this recurrence" implies
adding the EXDATE), but not for syncing.
May I add a CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY mode?
> If a backend doesn't support the semantic, then there's not much that
> can be done. But the file backend should be able to to handle it,
> therefore I consider it a bug that it removes all instances in this
> case.
>
> I'll look into fixing this.
I have a patch ready. Will continue to test and send when the rest also
passes my tests.
> > > 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.
>
> First things first ;-) Let me fix the removal, then look into this
> problem here.
ECalView is indeed odd. My initial understanding is that the file
backend will never send information about removed detached recurrences,
so rid is always empty.
What I get instead when removing a detached recurrence is a "master
modified" with EXDATE set. I suspect that the Evolution UI uses that to
remove the corresponding detached recurrence. Does anyone know whether
that is the case?
If I introduce the CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY, then
EXDATE won't be set and a real "object-removed" with rid set will be
needed.
--
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?
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. > though this > operation doesn't seem to have much sense to me. It's certainly not a common operation, but the API should allow it nevertheless, because otherwise correct synchronization between a database where such an operation took place (for whatever reason) and EDS is hard. > 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. If a backend doesn't support the semantic, then there's not much that can be done. But the file backend should be able to to handle it, therefore I consider it a bug that it removes all instances in this case. I'll look into fixing this. > > 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. First things first ;-) Let me fix the removal, then look into this problem here. -- 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?
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 evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
