[Evolution-hackers] [EDS PATCHES] ecal item semantic (was: [Fwd: Re: e_cal_remove_object_with_mod() + empty rid: semantic?])

2011-06-02 Thread Patrick Ohly
Hello Chenthill!

You are the calendar maintainer, right? Do you have some time to review
these patches? On this occasion let me add some further explanation of
the motivation for this patch series.

Traditionally, libecal has implemented parts of the semantic typically
associated with a UI: for example, it implements ensure that a
recurring event does not occur at this point in time, no matter what it
takes to achieve that. I consider this a high-level API.

The low-level API would be remove/add/modify this VEVENT. The libecal
API *looks* like it supports that and according to our previous
discussion is meant to (see the comments about
e_cal_remove_object_with_mod()), but the actual implementation differs.

This is a problem for sync operations, where that semantic is
implemented elsewhere and the calendar storage has to mirror the
operations done there (CalDAV/SyncML server in SyncEvolution; KCal in
the MeeGo architecture).

Therefore this patch series adds the missing operations. This is done so
that the file backend can replace other local storages that EDS is being
compared against. I understand that the vision of EDS goes beyond just
being a local storage, but that's irrelevant in the context of such
comparisons (unfortunately).

Bye, Patrick Ohly

On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote:
 I'll do it as uid[\nrid] 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

From 2e128c63a4a9dd64a3a327262498deb869a119f7 Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
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
- 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 

Re: [Evolution-hackers] Issues with new EBook dbus implementation

2011-06-02 Thread Patrick Ohly
On Fr, 2011-05-27 at 11:59 -0400, Matthew Barnes wrote:
 On Fri, 2011-05-27 at 16:49 +0200, Milan Crha wrote: 
  Maybe it can pump them, but it doesn't deliver them, as far as my tests
  showed, because they are usually delivered on idle, which never happen
  with blocked main loop. That's the reason why I added there this loop.
  Only notice that this loop is running for sync calls, and only if it's
  done from the main thread. The async calls and sync calls from a
  dedicated thread doesn't do any such thing. You may not use sync calls
  in your application, preferably. (Same as evolution shouldn't, which is
  subject to change, to use the EBOok/CalClient APIs directly.)
 Can't we just consider it a programming error for a D-Bus method to be
 called synchronously from the main thread?  I don't see any reason to
 support this case since it would be by definition a bug.

I beg to differ. A command line tool like SyncEvolution is perfectly
usable with blocking the main thread in the synchronous API calls. Or
rather, it works as good as the synchronous API implementation.

One problem are timeouts. The other is that the calls don't detect when
the server dies because the corresponding D-Bus signal is not delivered
(seen in older EDS releases, not sure how relevant it is on master).

As Alexander said, the synchronous API serves a useful purpose.
SyncEvolution is one, simple tests another. +1 for keeping it and fixing
it so that it really works.

Bye, Patrick Ohly

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...