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

2011-05-11 Thread Patrick Ohly
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.
 it sounds like you might find useful an addition of a reverse function
 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

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

Re: [Evolution-hackers] New 'eclient' branch in eds

2011-05-11 Thread Milan Crha
On Fri, 2011-04-29 at 07:24 -0400, Matthew Barnes wrote:
 On Fri, 2011-04-29 at 06:59 +0200, Milan Crha wrote: 
  There was just a little problem with ECalView, which had 'client'
  property, which is referring to ECal, instead of ECalClient, and I was
  forced to invent different name for it. But after a bit of sleeping
  and small thinking I might be wrong on this point too, as it should be
  easy to define EBookClientView/ECalClientView and keep old
  EBook/CalView-s as they are, at least their public API.
 Cool.  That was my initial thought too but didn't know how much extra
 work that would be.

so I did. There are new EBookClientView/ECalClientView defined. They use
exactly the same interface, with same signal names defined and their
signatures, the only difference is function naming and the GDBus object
used at the background. Consider it as the first step on the merge
common code of cal/book factory and cal/book view, which will make it
easier to adapt to such change in the future.

As I mentioned earlier, factories and views, all concrete
implementations and gdbus stubs can be merged and mostly reused between
calendar and addressbook factories. The only issue is compilation order
(some file placement restructuralization will be needed, for example to
be able to define EClientView and have it available in e-client.h, but
also in e-cal-client.h/.c and e-book-client.h/.c for exact

I noticed one difference between factories, recently. The calendar
factory keeps running all backends for all the time the factory is run
(since the backend is opened for the first time), even when no consumers
exist. The addressbook factory frees the backend as soon as the last
client is gone. Each has its advantages for sure. I'm mentioning it here
only to be aware of such difference and to anyone going further with the
merge idea to pick the better of them. I'm not sure which it is, though.

I'm not going any further in this merging effort, because I do not think
it breaks anyhow the EClient idea as is. The merging can be postponed to
any time later, even for 3.4 or beyond, from my point of view.

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

Re: [Evolution-hackers] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf

2011-05-11 Thread Christophe Dumez

No, I'm definitely not working on this (EDS), I thought you were :)
I actually followed Patrick's advice and I executed Evolution once so that it 
created the system addressbook. This way I can work around the bug and keep on 
working on the QtContacts backend for EDS. I don't have time to look into EDS 
code for now (I'm not familiar enough with EDS internals to do a quick fix).

Christophe Dumez.

-Original Message-
From: David Woodhouse [] 
Sent: Wednesday, May 11, 2011 2:26 PM
To: Dumez, Christophe
Cc: Patrick Ohly; Evolution Hackers;
Subject: RE: [PATCH 1/2] e_cal_new_system_foo() should create corresponding 
source in GConf

On Tue, 2011-05-10 at 11:40 +0100, Dumez, Christophe wrote:
 I have tested the patch but it does not seem to help. I don't know
 what the reason is yet.

I'm going to assume you're still happily working on this and don't need
my assistance, until such time as you turn up on the #evolution IRC
channel and bug me about it. OK? :)


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