Re: [Evolution-hackers] freeing evolution data structures

[Ross Burton]

On Mon, 2005-09-12 at 15:16 +0200, Alexander Dreweke wrote:
> 1:
> Is there a function that frees all the data structures and the memory
> that was allocated be g_type_init()?

No.

> 2:
> I get the ESourList for the address books by:
> 
>   ESourceList *gconf_source_list =
> e_source_list_new_for_gconf_default("/apps/evolution/addressbook/sources");
> 
> How can I free the memory that for this ESourceList? I've tried:
>   
>   g_object_unref(gconf_source_list);
> 
> But this produces, the following runtime warnings:
> 
>   GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT
> (object)' failed
> 
> So that doesn't seem to be the right way, but when I use:
> 
>   g_free(gconf_source_list);
> 
> I still have a memory-leak.

g_object_unref is the correct method here, so this is a bug in your code
somewhere else.


> 3:
> I've got an similar problem with the following GSList:
> 
>   GSList *groups = e_source_list_peek_groups(gconf_source_list);
> 
> When I try to free the GSList with:
>   
>   g_slist_foreach(groups, (GFunc) g_object_unref, NULL);
>   g_slist_free(groups);
> 
> I get warnings that "g_object_unref: assertion `G_IS_OBJECT (object)'
> failed" like for the ESourceList and when i use g_free instead of
> g_object_unref then i still have a memory-leak.

By calling peek_groups() you don't have to free the list.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] standalone e-d-s

[Ross Burton]

On Tue, 2005-09-20 at 18:10 +0200, Leen Toelen wrote:
> a while ago I saw a mail from Ross Burton that he is working on a
> D-Bus port of e-d-s. When this is integrated, does it mean that e-d-s
> can run completely standalone from evolution? I know that calenaring
> for example works in standalone mode, but will the d-bus e-d-s handle
> all the logic (mail receiving, spam check, indexing,...) and will
> evolution become just a GUI on top of that? Or will evolution still be
> needed for the mail part.

The DBus port simply replaces the CORBA IPC in the calendar and
addressbook with DBus.

e-d-s is totally stand-alone from Evolution at the moment, and doesn't
depend on Evolution for any of it's functionality.  The mail APIs are
low-level though and don't handle receiving etc, but I believe that is
part of the plan for the next release.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Valgrind and evolution

[Ross Burton]

On Mon, 2005-09-26 at 08:55 -0600, Veerapuram Varadhan wrote:
>   3) Are there any other options to valgrind that could give me a more
> larger stack trace than this?

--num-callers=...

>   4) Any other valgrind options available to fine-tune leak detections?

I use --leak-resolution=high to avoid Valgrind merging stack traces
which are not from the same problem.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Re: [maemo-developers] Ross' D-BUS port of evolution-data-server on maemo x86

[Ross Burton]

On Wed, 2005-09-28 at 01:39 +0200, Philip Van Hoof wrote:
> Other than that what I basically had to do was to disable groupwise. And
> then everything works out fine.

Depending on the age of your checkout, use either --disable-soup or
--disable-groupwise.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

[Ross Burton]

On Thu, 2005-11-24 at 16:33 +0800, Irene wrote:
> Currently, the MD5Context structures in
> evolution-data-server/libedataserver/md5-utils.h and
> evolution/e-utils/md5-utils.h are different with the first one not
> having a doByteReverse member. 

Hm, that would be my fault: I've been working with e-d-s and cleaned up
the libedataserver/md5-utils to remove the doByteReverse member.  The
obvious solution is to remove md5-utils from e-utils.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

[Ross Burton]

On Thu, 2005-11-24 at 09:19 +, Ross Burton wrote:
> On Thu, 2005-11-24 at 16:33 +0800, Irene wrote:
> > Currently, the MD5Context structures in
> > evolution-data-server/libedataserver/md5-utils.h and
> > evolution/e-utils/md5-utils.h are different with the first one not
> > having a doByteReverse member. 
> 
> Hm, that would be my fault: I've been working with e-d-s and cleaned up
> the libedataserver/md5-utils to remove the doByteReverse member.  The
> obvious solution is to remove md5-utils from e-utils.

It looks as if the md5-utils in e-util isn't used at all in Evolution,
OK to remove it from evolution HEAD?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

[Ross Burton]

On Thu, 2005-11-24 at 18:36 +0800, Irene wrote:
>   Md5-utils.ch are not the only files that are duplicated. Most of the
> files in evolution/e-util have similar copies in
> evolution-data-server/libedataserver. We are worried that in the future,
> if files in libedataserver are modified with their counterparts in
> e-util unchanged, more annoying bugs will come into being. 

I've created a wiki page http://live.gnome.org/EvolutionEUtilDieDieDie
listing the files which are identical, which are different, etc, to
track this.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

[Ross Burton]

On Fri, 2005-11-25 at 23:49 +0530, Shreyas Sriniavasan wrote:
> On Thu, 2005-11-24 at 16:48 +0530, Harish Krishnaswamy wrote:
> > > > Md5-utils.ch are not the only files that are duplicated. Most 
> > > > of the
> > > > files in evolution/e-util have similar copies in
> > > > evolution-data-server/libedataserver.
> > Thanks Ross :-). That really gets us moving to the next step.
> > 
> > Shreyas had taken the cause up [http://go-evolution.org/Evo2.6#Misc]
> > early during the cycle and IIRC, had started doing something on it too. 
> > Shreyas ?
> 
> Oh well, i had started doing something about it but it would entail 
> moving most of the duplicate code out of e-util. This ofcourse would 
> mean that most of the current e-util dependencies would then also
> depend on libedataserver. We never reached a consensus on whether thats
> a valid thing to do. If we can have consensus on that then doing it is
> just massive sed-awk operation. Ofcourse, a lot of those code werent in 
> sync either when i last checked. We need to figure out if we need to 
> make a new gal out of libedataserver. It needs to have stuff which most of 
> evolution and e-d-s can link to.

As evolution obviously depends on libedataserver already, surely for the
files which are identical there is no problem at all?  That leaves the
files which have the same name yet are different (e-account, e-util) to
be merged somehow, and then e-util can become a place for purely
Evolution utility functions.

http://live.gnome.org/EvolutionEUtilDieDieDie summarises the status for
each of the files in e-util/.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

[Ross Burton]

On Mon, 2005-11-28 at 11:23 -0500, Jeffrey Stedfast wrote:
> EAccount and EAccountList are private to Evolution app and should not be
> used inside e-d-s

Would it be best to rename the e-account and e-account-list
files/functions in e-d-s then, as they are used and there is obviously
potential for incorrect symbol resolution?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils

[Ross Burton]

On Mon, 2005-11-28 at 12:23 -0500, Jeffrey Stedfast wrote:
> what uses them?

>From a very rough grep:

./calendar/libedata-cal/e-cal-backend-util.c
./servers/exchange/storage/exchange-account.c

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Feedback from Slashdot

[Ross Burton]

On Wed, 2005-12-07 at 15:08 +1100, Martin Sevior wrote:
> I fully agree with with the following two points:
> 
> 1. Evolution deletes mail by putting it into a virtual folder and hiding
> the original message in your inbox. This is ok and seamless to the end
> user UNLESS you happen to also use webmail. In which case your inbox
> will be cluttered by messages you thought you'd gotten rid of ages ago.
> The evolution team has flat out refused to address this issue and has
> been calling this 'not a bug' (which is true) since 2001.

If the webmail system is displaying messages which are quite clearly
marked as deleted, that's a bug in the webmail system.  If I delete a
message in Evolution (which then gets striked out as I have Hide Deleted
Message unchecked), when I view the same folder with Mutt the deleted
messages are marked as Pending Delete.  Exactly what is expected.  If
you want Evolution to really delete all pending messages when it quits,
select Empty Trash On Exit.

> 2. Same as above but for Junk Mail.
> 
> I use evolution as my primary email system but sometimes I have to use
> webmail. When I do, all the nicely identified and hidden spam reappears
> in both webmail and evolution.

From a guess it sounds like the webmail client is resetting flags it
doesn't understand.  Again, the solution is to empty the Junk folder.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Feedback from Slashdot

[Ross Burton]

On Wed, 2005-12-07 at 23:40 +1100, [EMAIL PROTECTED] wrote:
> Don't shoot the messenger. I use evolution. Here is what bugs me and
> someone who is in aposition to recommend evolution over a rival.
> 
> I'm just telling you these are real annoyances.
> 
> For instance. I often leave evolution running 24 hours a day on my
> workstation at work because then it nicely filters incoming emails into
> real imap folders.

Filtering on IMAP is sub-optimal due to various issues, it's recommended
to use server-side filtering in this case.

> Junk mail does not get filtered into a real imap folder so as soon as I
> connect with my webmail client, spam gets splattered back into my inbox.

The built-in junk filter (in my opinion) only works well when Evolution
fetches the mail itself, in the IMAP case this doesn't happen.

Have you tried creating another filter with the Messsage Is Junk test to
move all junk mail to a real folder?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Re: Questions about merging evo/e-util/e-util.c into e-d-s/libedataserver/e-util.c?

[Ross Burton]

On Wed, 2005-12-21 at 09:31 +, Tor Lillqvist wrote:
> to 2005-12-22 klockan 12:13 +0800 skrev Simon.Zheng:
> 
> > #include "e-i18n.h"
> 
> This file should stay in evo/e-util, and also the e_gettext() function
> that it declares. e_gettext() should presumably be moved into a file of
> its own, e-i18n.c or e-gettext.c.

I've not looked at the source, but what does e_gettext() do that the
i18n functions in glib/gi18n.h doesn't?  Is it just legacy code from the
days before decent i18n in glib?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Re: Questions about merging evo/e-util/e-util.c into e-d-s/libedataserver/e-util.c?

[Ross Burton]

On Wed, 2005-12-21 at 11:08 +, Tor Lillqvist wrote:
> on 2005-12-21 klockan 10:45 + skrev Ross Burton:
> 
> > I've not looked at the source, but what does e_gettext() do that the
> > i18n functions in glib/gi18n.h doesn't? 
> 
> Well, e_gettext() calls bindtextdomain(E_I18N_DOMAIN,
> EVOLUTION_LOCALEDIR) and bind_textdomain_codeset(E_I18N_DOMAIN, "UTF-8")
> the first time it is called. I don't think any GLib functionality would
> take care of that?
> 
> OTOH, those calls could well be taken care of by the appropriate main
> program, i.e. shell/main.c. And actually, surprise surprise, there
> already are calls bindtextdomain (GETTEXT_PACKAGE, EVOLUTION_LOCALEDIR)
> and bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8") there. Presumably
> the E_I18NDOMAIN in evo/e-util/e-util.c is the same as GETTEXT_PACKAGE
> in main.c? Could uses of e-i18n.h be replaced by, eh, gi18n.h? e-i18n.h
> include also gnome-i18n.h. what role does that play? Does the fact that
> Evo HEAD should be buildable against GLib 2.4 (and whatever is the
> corresponding old GNOME version) confuse issues any further?

gnome-i18n is deprecated and replaced with gi18n.h in Glib, so that
isn't a problem.  glib/gi18n.h (Evo) and glib/g18n-lib.h (EDS) were
added in Glib 2.3.1, so that isn't a problem either.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] fix bug 323853 by GtkFileChooserButton

[Ross Burton]

On Wed, 2006-01-25 at 17:14 +0800, Nancy Cai wrote:
>   There are four modes of GtkFileChooser: open file, save file, select
> folder, create folder. In the open mode, we must open an existing files,
> but can't input the file name by hand as GnomeFileEntry.I think it's the
> matter of GTK.

Press the button to open the file selector, and type a name.  When you
hit a key the filename entry pops up.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Should I replace GtkFileEntry by GtkFileChooserButton in glade?

[Ross Burton]

On Mon, 2006-02-06 at 19:03 +0800, Nancy Cai wrote:
>   I want to replace GtkFileEntry by GtkFileChooserButton in mail
> preference. But some widgets are assigned by glade such as
> "mail-config.glade".Should I replay these widgets in glade? Then it'll
> only work with gtk version 2.4 and later. 

libedataserverui already uses GtkFileChooserButton, so this isn't a
problem.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] evolution and gstreamer

[Ross Burton]

On Tue, 2006-02-07 at 10:57 -0500, Jeffrey Stedfast wrote:
> I don't believe Evolution uses gstreamer directly at all.

The "audio-inline" plugin uses GStreamer, and it hasn't been ported yet.

http://bugzilla.gnome.org/show_bug.cgi?id=329629

The good news is that its on the 2.5 milestone tracking bug.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] ... and how camel should be

[Ross Burton]

On Tue, 2006-02-14 at 10:47 +0530, Parthasarathi Susarla wrote:
> The disk summaries branch does something on those lines, but it also
> means a lot of disk I/O than before, and only after prolonged
> testing/usage would we now how well it would work.

Note that some of us have ~/ on NFS, which isn't know for its speed.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Announce : Evolution 2.5.92, EDS1.5.92, Evolution-exchange 2.5.92 and Gtkhtml 3.9.92

[Ross Burton]

On Wed, 2006-03-01 at 12:57 +, Paul Hands wrote:
> Unfortunately, when trying evolution data server, I get  the equally 
> mystifying..
> e-msgport.c:39:18: error: nspr.h: No such file or directory

You need the NSPR/NSS headers, or disable smime.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] building evolution-data-server against the already installed libdb

[Ross Burton]

On Mon, 2006-02-27 at 17:49 -0500, Mikhail Teterin wrote:
> Hello!
> 
> I'm trying to convince the maintainers of the evolution-data-server
> FreeBSD port (<http://freshports.org/databases/evolution-data-server>)
> to build the software against the db4-version installed by the separate
> port of SleepyCat's db4 (<http://freshports.org/databases/db43>).
> 
> I'm using the thus built evolution (against db-4.3.29) to type this
> message, but they remain hesitant, because of the past problems they
> encountered trying to build evolution using the already installed db3
> instead of the version then-bundled with evolution.
> 
> I'm guessing, you used to have modified version of db3, which allowed it
> to work, where the "standard" version did not. Is there anything like
> that in the db4.1 version bundled with e-d-s 1.4.2.1, or can we safely
> use any reasonably recent version of db4?
> 
> Moreover, perhaps, you can be convinced to stop the bundling of db4
> completely and turn it into just another pre-requisite?

http://bugzilla.gnome.org/show_bug.cgi?id=319393 contains a patch we've
been using in the DBus port of EDS to use a dynamic libdb.  Instead of
simply hacking away at the makefiles it adds an option, so is suitable
for integration.

EDS comes with a copy of libdb 4.1.  It was copied as back in the early
days of Evolution some people had db3, and some had db4, but the file
format changed.  The solution to this was to add migration logic from
db3 to db4 in EDS, and to enforce EDS linking to db4.1 by embedding the
source.

Recently the DB file format hasn't changed, so the problem is moot.
I've been running EDS with a dynamically linked libdb 4.1, 4.2 and 4.3
without any problems, on both Intel and ARM.

I really would like this patch to be merged into EDS for G2.16, if only
for the memory reduction: libdb is statically linked into both the bdb
addressbook backend and libedataserver, at a cost of 600K each time.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] How do I use e_passwords_ask_password() without segvs?

[Ross Burton]

On Wed, 2006-04-26 at 12:27 +0200, Jules Colding wrote:
> I am trying to invoke e_passwords_ask_password() from a standalone
> application as well as from my Calendar backend. Both attempts fails
> miserably with a segv. The segv is in gtk_icon_set_render_icon() and I
> have no idea of why this happens.

You don't call gtk_init() so any calls to GTK will randomly crash.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] emacs ChangeLog macro

[Ross Burton]

On Mon, 2006-05-01 at 10:56 -0400, Jeffrey Stedfast wrote:
> I've noticed a lot of inconsistantly formatted ChangeLog entries so I'm
> sending out this email so the hackers can all add it to their .emacs
> file (since I'm guessing they don't have it?).

Note that M-x add-change-log-entry does that for me automatically, with
XEmacs in Ubuntu.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Directory structure re-organisation

[Ross Burton]

Hi,

So I've received mostly positive feedback towards merging the DBus port
of EDS back into CVS, so would like some feedback.  My fork has renamed
libebook and libedata-book to libebook-orbit and libdata-book-orbit, and
added libebook-dbus and libedata-book-dbus.  At configure time a symlink
is created from libebook and libedata-book to the relevant
implementations, so the backend build system doesn't need to be
modified.

I also symlink various files from libebook-dbus/ to -orbit, as they are
identical in both code bases.  These symlinks are stored in the
repository so will probably need to wait for the Subversion migration...

Are there any objections to this plan?  On Windows its sub-optimal as
the $(LN_S) will fall back to a cp -a, but I can't see a better clean
way of handling the two code bases without massive numbers of ifdefs in
source/makefiles.

http://svn.o-hand.com/view/eds-dbus/trunk/ is the repository for anybody
curious as to how the source is arranged.

Cheers,
Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] strtok camel from evolution-data-server

[Ross Burton]

On Thu, 2006-07-06 at 21:23 +0200, Philip Van Hoof wrote:
> Most Evolution people already know this. This is just the E-mail you
> guys have been asking about (well, actually most of you guys asked me to
> make a bug in bugzilla).
> 
> 
> The one laptop per child project, Nokia (maemo) and maybe sooner or
> later other vendors like PalmSource are getting more and more interested
> in tinymail.
> 
> Situation:
> --
> 
> Tinymail depends on Camel. Camel gets shipped with e-d-s. Tinymail
> doesn't use *any* of the other e-d-s softwares, libraries nor its data.

Not strictly true.  From camel/ in EDS HEAD:

#include 
#include 
#include "libedataserver/e-memory.h"
#include 
#include 
#include "libedataserver/e-time-utils.h"
#include "libedataserver/e-trie.h"
#include 

The MD5 code can be removed as I believe its in GLib 2.10 now (although
its early for a hard dep on that).  The sexp, iconv, msgport and memory
code is non-trvial and used in other libraries, so can't be just copied
into camel.

> Observation:
> 
> 
> >From reading code I *know* camel doesn't have to depend on e-d-s at all.
> It can very easily be cut-off from it. I could probably do this in a few
> hours work.

By copying lots of source, yes.

> The full e-d-s requires 23Mb disk space. Only Camel requires ~ 1MB disk
> space.

Don't install the full EDS.  You'll note that the 770 only contains the
addressbook code, and no groupwise/ldap/exchange support.  Yay for clean
packaging.

> Conclusion:
> ---
> 
> So or camel is going to be split from evolution-data-server, or I will
> fork camel.

This sounds like fighting talk.  Should we arrange a street brawl?
Shame this mail wasn't sent before GUADEC, a fight on the beach, fork vs
split, would have been good.


> Hacks like packaging tricks:
> 
> 
> I AM NOT going to require packaging tricks. Packaging tricks are hacks.
> I don't do hacks. Hacks are ugly. Hacks are win32. I didn't come to the
> opensource community to get myself stuck in hacks.
> 
> I strongly disagree with hacks. I don't support hacks. I will not use
> hacks. I will fork if I'm forced to use hacks.

Packaging the libraries as separate packages is not a hack, it's the
solution.  That way you only install what you need: libedataserver and
libcamel.

-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] strtok camel from evolution-data-server

[Ross Burton]

On Thu, 2006-07-06 at 22:49 +0200, Philip Van Hoof wrote:
> Yes sure. But packaging is often specific for all devices. There's
> mostly also no e-d-s nor camel packages for the target device. So
> developers basically have to do all this dirty work themselves.

There are EDS packages split into camel/ebook/ecal for OpenEmbedded (we
wrote them).  There are EDS packages for the 770 which only contain
ebook at the moment but we're in the process of extending that for the
full system (otherwise Dates won't link).  What devices are you talking
about?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

[Ross Burton]

On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote:
> Okay, forking Camel is not what I want. Nobody wants that. It's not a
> good idea.
> 
> However, it would be more easy (for me) if Camel would have its own
> configure.ac file. That way would it be more easy to do a 'make dist' of
> just Camel, I think.
> 
> The evolution-data-server configure.in could very easily forward the
> configure stage of Camel using AC_CONFIG_SUBDIRS()
> 
> I think it's even possible to pass variables from the first configure.in
> to the next configure.ac. And if not, I guess we can simply write-out a
> m4 file and m4_include() that one in the second configure.ac. For
> example in case you want to pass version information from a to b.

What advantages does being able to dist camel on its own have, over
simply packaging it in a separate package like OpenEmbedded and Debian
do:

$ apt-cache show libcamel1.2-8
Package: libcamel1.2-8
Maintainer: Takuo KITAME <[EMAIL PROTECTED]>
Architecture: i386
Source: evolution-data-server
Version: 1.6.1-0ubuntu5
Depends: libc6 (>= 2.3.4-1), libcomerr2 (>= 1.33-3), libedataserver1.2-7 (>= 
1.6.1), libegroupwise1.2-9 (>= 1.6.1), libglib2.0-0 (>= 2.10.0), libgnutls12 
(>= 1.2.5), libkrb53 (>= 1.4.2), libsoup2.2-8 (>= 2.2.92), libxml2 (>= 2.6.24), 
zlib1g (>= 1:1.2.1), libnss3
Description: Generic messaging library for evolution data servers
 The data server, called "Evolution Data Server" is responsible for managing
 calendar and addressbook information.

Before you can dist it as a separate package you'll need to remove the
use of libedataserver.  That might not be possible or realistic, so I'd
attempt that first.

If you find large bits of code that are only used in camel and are
currently in libedataserver, I'd propose moving them into camel:
libedataserver could do with slimming down.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

[Ross Burton]

On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
> > What advantages does being able to dist camel on its own have, over
> > simply packaging it in a separate package like OpenEmbedded and Debian
> > do:
> 
> It's cleaner in my opinion :-), and I can more easily create a tar.gz
> release.

Cleaner for what reasons?

> > Before you can dist it as a separate package you'll need to remove the
> > use of libedataserver.  That might not be possible or realistic, so I'd
> > attempt that first.
> 
> Or do all the libraries in evolution-data-server with their own
> configure.ac?

So you are proposing the following library packages:

libedataserver
libedataserverui
libebook
libedata-book
libecal
libedata-cal
libgroupwise

And then binary packages for the Groupwise helpers, the Exchange
helpers, and the server binaries themselves.

I'm also not sure where the backends would go in this scheme.

No, I don't think that is a good idea either.

> > If you find large bits of code that are only used in camel and are
> > currently in libedataserver, I'd propose moving them into camel:
> > libedataserver could do with slimming down.
> 
> For example EMsgPort, is that used by something else but Camel?

By the magic of grep, libedataserverui/e-passwords.c uses e-msgport.c.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

[Ross Burton]

On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:
> On Wed, 2006-07-12 at 17:00 +0100, Ross Burton wrote:
> > On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
>  
> > > It's cleaner in my opinion :-), and I can more easily create a tar.gz
> > > release.
> > 
> > Cleaner for what reasons?
> 
> Because it will be more easy to pick which libraries you will use (in
> your application that integrates with the e-d-s framework).

This is only for the case of the developer who is both writing an
application and developing the underlying libraries, and is also only
using a subset of the libraries, right?  That is pretty much you.

The Evolution hackers are using the entirety of EDS obviously, Chris
Lord (Dates and Contacts developer) isn't developing the libraries (just
using the packages I produce for Maemo), and although the 770 uses only
the addressbook we disable Camel and Calendar at configure time.

There is no reason why you can't just take the eds tarball, build
packages, and use just libcamel.deb on Maemo, or any other platform.

X has taken the modular route, but in that case the composite tarball
was *huge*, and many parts of it hadn't changed for years.  There
splitting it up into separate packages made absolute sense (although it
did cause huge amounts of pain on the packages, LFS users still moan
about the modular packaging on xorg-list).  I don't see how splitting
EDS into ~10 library packages would help anyone apart from you, as you
don't want to have a large source tarball for a camel package.

[snip]
> At this moment, all those fall under the name of "evolution comma data
> comma server". Some of these libraries (like Camel) don't necessarily
> have "anything" to do with the Evolution data that is being managed by
> the data server of Evolution.

"hyphen", not "comma".

EDS is a far better place for Camel than in Evolution itself, which is
where it is.  EDS is a library for storing and accessing PIM data, and
email is part of this.

> The E-mails and, folder-summaries, state data and summaries of Camel are
> *not at all* being managed by Evolutions data server. It's simply
> totally unrelated to the Evolutions data server. It looks like even some
> Novell employees don't know that, probably cause it's being marketed as
> "one" package.

Calendar data isn't being stored by the addressbook server either.  That
isn't a great argument.

[snip rant]

> Conclusion .. all this coupling with Evolution and Evolution Data Server
> is making it harder for application developers to actually *use* the
> provided functionality.

You are talking entirely from a packaging point of view.  Yes, it would
be nice to have an option to at configure time disable the address book,
or the calendar (I have the latter in eds-dbus).  Being able to enable
and disable backends selectively would also be nice.  I'm sure patches
for this would be considered.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

[Ross Burton]

On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:
> I wasn't (am no longer) proposing to move "camel/" out of e-d-s. I was
> proposing to put a configure.ac file in its directory. Moving Camel out
> of evolution-data-server/ is not the scope nor point of this thread.

For what purpose?  Camel depends on libedataserver.

> > Calendar data isn't being stored by the addressbook server either.  That
> > isn't a great argument.
> 
> And I question ... do all applications that want to use calendaring (and
> only calendaring) have to depend on most of the Evolution components?
>
> Right now, if you translate that to Camel and E-mailing, it depends on
> which distribution you have. On most Redhat based ones: yes. On Debian
> based ones: no. Is there clarity? no. Is it making it more easy to
> develop a pure "E-mail" application and to document which dependencies
> you have (maybe even letting packagers share the same dependencies): no.
> 
> The list of reasons (all valid ones, it's not because *you* mark them as
> rant that it also *is* rant) goes on and on and on.

So you've found a problem with the Red Hat packaging, in that it treats
all of EDS a single library.  File a bug with Red Hat, and notice that
Debian, Maemo, and OpenEmbedded (at least) already have split EDS
packages.

In the scheme of things this is a very minor issue which effects very
few people.  I'd prefer to see effort spent on fixing bugs and memory
leaks.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Hot Patch Action

[Ross Burton]

Hi,

We're coming up to the freezes, so I thought I'd ping the lists with
some patches that are sitting in bugzilla for libebook:

http://bugzilla.gnome.org/show_bug.cgi?id=318880
Change an internal table to match an external enum, thus changing linear
searches into array index lookups.

http://bugzilla.gnome.org/show_bug.cgi?id=347899
Adds some more mutators of EVCard so that values and parameters can be
removed without having to jump through loops.

http://bugzilla.gnome.org/show_bug.cgi?id=330255
Add a new query, e_book_query_vcard_field_exist(), to match on arbitrary
vcard fields.

All of these patches are in Maemo so have been tested.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal

[Ross Burton]

On Sat, 2006-07-22 at 12:04 +0200, Philip Van Hoof wrote:
> I have customers and end-users that are building mobile devices that
> will *not* come with contactbook nor addressbook functionality. Why
> would I want to ship a libedataserver that contains 1.5 megs of
> functionality that my Camel isn't using? The answer is rather simple: I
> don't want that: so, that's why .. camel-lite-builder, another hack.

As I pointed out before the 1.5M impact is due to statically linking
BDB.  If your target system has BDB, and frankly a huge number of
devices have it, then dynamically link and libedataserver is nearer
100K.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Error while trying to obtain ESource list

[Ross Burton]

On Tue, 2006-07-25 at 19:19 -0400, Peter Colijn wrote:
> I think the issue here is that g_type_init() is not being called.
> Generally for gnome programs, the first thing main() should do is call
> gnome_program_init, which will call the init()s of a bunch of
> libraries and make sure that everything is happy. I can get
> e_source_list_new() to not complain with the following code:

libgnome is being deprecated, so unless you have a massive requirement
to use GnomeProgram, the gtk_init (&argc, &argv); will be sufficient.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Adding documentation to Evolution's code

[Ross Burton]

On Fri, 2006-08-11 at 16:09 +0530, Mayank Jain wrote:
> But using gtk-doc style commenting create a problem?
> When I go ahead & document the non-public functions, their doc will
> also be included in gtk-doc output when its generated.
> 
> This will grossly confuse the API user as he'll be trying to use a
> private function.

I don't believe that private functions will be included in the docs, as
(AFAIK) it uses the headers to determine what to output.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Adding documentation to Evolution's code

[Ross Burton]

On Fri, 2006-08-11 at 16:40 +0530, Mayank Jain wrote:
> On 8/11/06, Ross Burton <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-08-11 at 16:09 +0530, Mayank Jain wrote:
> > > But using gtk-doc style commenting create a problem?
> > > When I go ahead & document the non-public functions, their doc will
> > > also be included in gtk-doc output when its generated.
> > >
> > > This will grossly confuse the API user as he'll be trying to use a
> > > private function.
> >
> > I don't believe that private functions will be included in the docs, as
> > (AFAIK) it uses the headers to determine what to output.
> 
> Lets take an example...
> reset_layout is a function related to EText widget & is private to it
> and is in file
> $evo/widgets/text/e-text.c
> 
> /**
>  * reset_layout:
>  * @text: The text widget on which this function will be called
>  *
>  * Resets layout to its default values, checks for an already existing layout
>  * resets it to default values if it exists else create a new layout
> from #create_layout call
>  *
>  * Return value: Nothing
>  **/
> 
> If i include this as doc for the reset_layout function, will it be
> included in the gtk-doc output?

As far as I know, if its a static function and thus it isn't in
e-text.h, then it won't be output.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] More e-d-s ABI breakage ?

[Ross Burton]

On Fri, 2006-08-11 at 15:54 +0100, Michael Meeks wrote:
> > The #313533 patch was vital for Ross Burton's dbus-based EDS and running
> > EDS on devices (say Nokia 770) would not be possible w/o this change.
> 
>   Nonsense - at least the link above has no API change that is necessary
> for dbus or Nokia 770 support - unless I'm missing something huge; good
> buzz-words though :-)

The change was required for the 770 as ferrying the photos over the bus
every time the contact is transferred is too large a hit for the
relatively low number of places that a photo is used.  The solution was
to expand the photo struct to support URIs as well as inline, and then
store the photo on disk.

If it's required it might be possible to revert that change and
introduce an alternative.  As you say, a "photo2" property that returns
a new type should be sufficient, I'll have a look later.

I have Grand Plans to write a replacement for EVCard and EContact
though.  I've been adding new API to e-vcard to make it more usable, but
that is just complicating the API for no gain.  Extending EContact is a
pain as all of the data types are public structs with no padding.
EContact also manages to hit that sweet spot between
complicated-but-powerful and easy-but-limited, so it's
complicated-and-limited at once.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Why a bitfield in CamelOfflineFolder?

[Ross Burton]

On Thu, 2006-11-30 at 09:43 +0100, Jules Colding wrote:
> Is this really necessary?  
> 
> struct _CamelOfflineFolder {
> CamelFolder parent_object;
> 
> unsigned int sync_offline:1;
> };
> 
> Wouldn't it be much better/simpler/cleaner simply to do:
> 
> struct _CamelOfflineFolder {
> CamelFolder parent_object;
> 
> gboolean sync_offline;
> };

gtypes.h says:

typedef gint   gboolean;

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Why a bitfield in CamelOfflineFolder?

[Ross Burton]

On Thu, 2006-11-30 at 11:07 +0100, Jules Colding wrote:
> Sorry, I must be dim-witted here, but I don't understand your answer.
> The present definition of CamelOfflineFolder has:
> 
> unsigned int sync_offline:1;
>  ^^<== bit field 
> 
> I'm asking why we don't simply do:
> 
> gboolean sync_offline;
> 
> instead?

I'm presuming to save memory -- maybe the folder is nested in another
struct and the compiler can compact the bitfields into a single word.

However that doesn't appear to be the case so in this situation a
gboolean would use the same amount of memory as the int:1.  I'm guessing
this was a style choice: always use a bitfield so future boolean flags
are compacted.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] RFC: Evolution's library requirements

[Ross Burton]

On Tue, 2006-12-05 at 16:28 -0500, Matthew Barnes wrote:
> > I suggest that on upstream CVS, Evolution  should depend on the most
> > recent stable versions of the libraries available in the corresponding
> > GNOME release (Evolution 2.9.x/2.8.x on GNOME 2.16, 2.6.x on GNOME
> > 2.14). This is similar but not exactly the same as what Matthew has
> > outlined in Bug 380534. I agree that the configure scripts need to
> > hard-enforce these dependencies while building the packages.
> 
> Did you mean Evolution 2.9.x/2.10.x on GNOME 2.16?  Or will Evolution
> 2.10.x (which should essentially be 2.9.92 plus bug fixes) suddenly
> depend on GNOME 2.18?
> 
> I think it makes more sense for the development and _subsequent_ stable
> releases to share the same library requirements.  The requirements can
> then be bumped when the next development cycle starts (after CVS is
> branched).  So, for example, 2.11.x/2.12.x will depend on GNOME 2.18.
> 
> I agree that depending on the libraries provided by the most recent
> _stable_ GNOME release is the right thing to do.

If this is what Harish meant, I agree.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Removing code duplicated in GLib

[Ross Burton]

Hi,

I noticed today that EDS 1.9.1 bumped the Glib requirement to GLib 2.10,
which is great news as there is much in that release we can use, and
remove duplicated code from EDS.

http://bugzilla.gnome.org/show_bug.cgi?id=383686 is one such patch: it
turns e_util_mkdir_hier() into a one-line wrapper around
g_mkdir_with_parents() (no fallback any more for pre-GLib 2.8), marks it
as deprecated, and replaces all of its callers in EDS with the GLib
call.

If this gets the OK to commit, I can make more patches: a fair bit of
code is conditionally using GMappedFile for example when we can now
assume it is present.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] evolution-data-server/calendar/libical and SVN

[Ross Burton]

On Tue, 2007-01-02 at 14:37 +, Mark McLoughlin wrote:
> Hey there,
>   As per:
> 
>   http://live.gnome.org/SubversionMigration
> 
>   evolution-data-server will not currently build from SVN because libical
> isn't automatically checked out.
> 
>   One option would be to do:
> 
>   $> cd evolution-data-server/calendar
>   $> svn propset svn:externals http://svn.gnome.org/svn/libical/trunk
> 
>   I see a couple of problems with that though:
> 
>   - The libical module will be checked out using anonymous SVN, meaning 
> evo hackers wouldn't be able to directly hack on that checkout
> 
>   - When you branch, the branched evolution-data-server will still 
> refer to libical trunk. You'd need to modify the svn:externals 
> property to refer to the libical branch

Those problems might not be a real issue, as nobody really hacks on
libical.  However, if nothing else uses it, maybe it should just be
copied into eds source tree?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] e_contact_set() and IM fields

[Ross Burton]

On Sun, 2007-03-18 at 22:35 -0700, Travis Reitter wrote:
> I've been working on a program which uses evolution-data-server for its
> EContact data storage/retrieval.

As someone who has written a multitude of EDS clients, my first piece of
advise to people using libebook is "don't use EContact".  The first
thing you do when you get an EContact* is cast it up to EVCard*.  Yes,
it's more work, but because you are telling it exactly what to do, it
does what you expect.

I do plan on making a replacement for EContact at some point too...

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Minimize to Systray

[Ross Burton]

On Sun, 2007-04-01 at 16:19 -0500, Benjamin Gramlich wrote:
> I've already tried that program, but I don't very much like it.
> 
> Is there an intentional design reason why such a feature has not been
> implemented?

Yes.  The "system tray", correctly called the notification area in
GNOME, is for notifications.  Not for random applications that you
decide should be put there and not the window list when you minimise
them.

If you want to dock arbitrary applications into the tray, use AllTray.

http://alltray.sourceforge.net/

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] libebook scalability

[Ross Burton]

On Mon, 2007-04-02 at 01:12 +0200, Øystein Gisnås wrote:
> I discovered a bottleneck for addressbook performance with large
> addressbooks. Details at
> http://n800evolution.blogspot.com/2007/04/libebook-scalability.html
> 
> A proposed fix is attached. I'm not sure if order matters when
> returned from the backend? Does anyone know? If not, g_list_reverse
> can be omitted.

I also pushed a patch into bugzilla to do this, because eds-dbus has had
that patch for a long time.  You can omit the reverse as ordering from
the backend isn't specified.

Let me get dressed and so on and I'll file a bug with a set of similar
optimisations in e-vcard (which, IIRC, is the biggest bottleneck once
the server side book view optimisations landed).

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] libebook scalability

[Ross Burton]

On Mon, 2007-04-02 at 09:03 +0200, Øystein Gisnås wrote:
> I'd also love to create scripts, code and test data to test
> performance of some of the most important functions. Then we would be
> able to track performance over time in a more scientific way.

http://burtonini.com/bzr/eds-tests/

Check that out with bzr and you get a few tools:

1) a dummy backend for libedata-book.  Ask for a contact and you get the
same one back.  As for a contact list and you'll always get the same 10.
Ask for a book view and (mwhaha) you'll get 10 contacts.  This makes
profiling the EDS infrastructure easier as the backend has almost zero
overhead.  I should probably reduce the number of contacts returned in a
book view as malloc tends to swamp the profiles now.

2) eds-bookview.  A test application that will open and repeatedly
request book views for a given number of times and URL.  For example:

$ eds-bookview --uri dummy:/// --repetition 10 --silent

Will visibly do nothing for a few minutes but EDS will be very busy.
Attach a profiler and come back 10 minutes later to discover that EVCard
parsing is still primary bottle neck in eds-dbus.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] libebook scalability

[Ross Burton]

On Mon, 2007-04-02 at 10:18 +, Srinivasa Ragavan wrote:
> This sounds really great. If you have the bugs/patches please post them
> across. 

 e-vcard.c |  494 +-
 1 file changed, 232 insertions(+), 262 deletions(-)

Urgh.  Give me a minute or ten...

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] libebook scalability

[Ross Burton]

On Mon, 2007-04-02 at 10:18 +, Srinivasa Ragavan wrote:
> This sounds really great. If you have the bugs/patches please post them
> across. 

http://bugzilla.gnome.org/show_bug.cgi?id=425464

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] [PATCH] Const/static additions to e-d-s/calendar/libical

[Ross Burton]

Hi,

http://bugzilla.gnome.org/show_bug.cgi?id=318176 contains a patch to
liberally scatter const and static keywords over libical, which
dramatically reduces the amount of per-process memory.  It has been
sitting in bugzilla since October 2005... can this be reviewed?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] More patches

[Ross Burton]

Whilst I'm mailing evolution-hackers...

http://bugzilla.gnome.org/show_bug.cgi?id=385078
When calling e_contact_get(_const) don't go via GObject properties.
This saves a lot of time for the common case.

http://bugzilla.gnome.org/show_bug.cgi?id=400970
Don't create custom marshallers when Glib provides them.  General
cleanup.

http://bugzilla.gnome.org/show_bug.cgi?id=318176
Liberally scatter const and static over libical, which moves many arrays
(which are often 25K each) into shared memory instead of relocated
per-process.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Lonely patches waiting review

[Ross Burton]

Hi,

>From our work on Pimlico, we've fixed a few bugs in EDS.  These are
already integrated into the DBus port, but need to be fixed upstream
too.

"libical cannot parse GEO properties"
http://bugzilla.gnome.org/show_bug.cgi?id=431722
This bug means that EDS fails to parse GEO properties in calendars, and
they get replaced with error messages.  This bug contains a simple
parser.

"e_cal_create_object does not set the uid on the icalcomponent"
http://bugzilla.gnome.org/show_bug.cgi?id=431135
If you do e_cal_create_object(), manipulate the object more, and then
try to e_cal_modify_object(), the server crashes.  This bug contains a
patch to set the UID in the component before returning back to the user.


-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Addressbook Maintainership

[Ross Burton]

On Fri, 2007-05-18 at 18:00 +, Srinivasa Ragavan wrote:
> It is with great pleasure I announce that Ross Burton joins me
> as "Addressbook maintainer". Ross is already the maintainer of Sound
> Juicer, Devil's pie, Contacts, Dates and Tasks. He has contributed many
> patches in Addressbook during his development of Contacts and also wrote
> the DBus port of Evolution Data Server. He started reviewing addressbook
> patches recently.

To avoid upsetting my colleagues I should point out that I've barely
touched Contacts and Dates (Chris Lord, Thomas Wood, Rob Bradford and
Tomas Frydrych are the main authors IIRC).

Thanks for the warm welcome, I hope to do a better job maintaining EDS
than I do with Sound Juicer...

Obviously one of my main goals for the next two release cycles is to
land and polish the DBus port of EDS.  I've started planning this on the
wiki[1], but extra hands are always appreciated.  If anyone would like
to help, please just say.

Regards,
Ross

[1] http://www.go-evolution.org/DbusPort
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Removal of implementation details from public API, any breakages?

[Ross Burton]

Hi,

Last week I committed a patch to libebook, and want to commit a patch to
libecal[1], which removes private functions and types from the installed
headers.  This has several consequences:

- e_cal_view_new() is removed
- ECalListener is removed
- ECalViewListener is removed

I believe that nobody is using these functions apart from libecal
itself, so this removal is safe.  However, I'd appreciate it if anyone
writing advanced clients to EDS (like Zimbra or Brutas) remove their
currently installed headers, apply the patch, and rebuild.

Thanks,
Ross

[1] http://bugzilla.gnome.org/show_bug.cgi?id=438727
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Removing libical fork, moving to new upstream?

[Ross Burton]

Hi,

I discovered last week that there is an attempt to resurrect libical
from non-maintainership, merge all of the patches from various forks,
and start making sane releases again[1].  Are the evolution team as
whole interested in merging their changes to libical upstream and
depending on it to be installed when a release is made with all of the
relevant changes?  libical isn't exactly a small library, and statically
linking it is a waste of memory for everyone.

I'll happily start working on extracting the changes to EDS and pushing
them into the new libical repository, if the Evolution team as a whole
agrees that the fork of libical will be dropped.

Ross

[1] http://sourceforge.net/projects/freeassociation/ -- last commit two
weeks ago!
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

[Ross Burton]

On Mon, 2007-05-21 at 12:15 +0530, Srinivasa Ragavan wrote:
> It will be great if you can mail the details on the address book stuff
> as well. I would like the libebook clients like OOo, etc to comment on
> this. 

The addressbook changes are very similar:

- e_book_view_new() is not public
- EBookListener and EBookViewListener are not public

As before, these are not usable outside of libedata-book, so clients
should not be aware of their existence.

I've had a quick look at the Zimbra Evolution code and it appears to not
use these either.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?

[Ross Burton]

On Mon, 2007-05-21 at 11:33 +, Srinivasa Ragavan wrote:
> >From the current discussion, it looks like we are safe. Can we do
> something like this for this release before we dung them out?
> 
> #ifdef E_D_S_DEPRECATED
> #include 
> #endif

The patches consist of removing functions or headers from the install,
these cannot be deprecated because they are still used by EDS itself.

I don't think there needs to be any notice: the headers and functions
are implementation details of libebook and libecal, and are not possible
to use outside of the implementation of libebook/libecal.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Addressbook Maintainership

[Ross Burton]

On Tue, 2007-05-22 at 21:30 +0200, Patrick Ohly wrote:
> On the other hand, does that mean that I should stop bothering you with
> reports about problems in the EDS DBus version of libecal, Ross? ;-)

Not at all, if it's going to be merged we want to fix all the bugs. :)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Improved vCard parser

[Ross Burton]

On Wed, 2007-05-30 at 07:59 +0200, Øystein Gisnås wrote:
> I posted some lines about improvements to the vCard parser, but it
> seems like getting multi-megabyte attachments take some time to get
> through to the mailing list. So I posted to my blog instead:
> http://n800evolution.blogspot.com/2007/05/improved-vcard-parser.html

Could you post the message itself, without any attachments?  There are
some point I'd like to make, but without the context of the original
post it would be tricky to read.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] XML APIs in evolution

[Ross Burton]

On Wed, 2007-05-30 at 16:42 +0200, Gilles Dartiguelongue wrote:
> The question is, what shall we do now ?

The need for a cast is part of the (IMHO wrong) design of libxml2, the
policy is that the libxml2 API requires UTF-8 strings, so they typedef
xmlChar to unsigned char*.  Application writers are then meant to run
all strings through UTF-8 conversion, or use xmlChar* if they know the
string is UTF-8.

Of course:

1. This breaks ASCII and UTF-8 string literals
2. GNOME uses char *UTF-8 strings internally, so the strings are always
valid

Sadly the correct solution is to cast everything to xmlChar*. :( If
there are some strings which are only used with the libxml2 functions
then declaring their type as xmlChar is better.  

I'll happily review a patch for evolution-data-server/addressbook
because the warnings there have been driving me insane recently.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Data storage question

[Ross Burton]

On Thu, 2007-08-09 at 00:33 -0400, administrator wrote:
> I'm trying to write a php script that will create mail accounts in
> evolution.
> So far, everything works fine and I seem to have all changes to files
> identified and covered, and all file and folder creation taken care of
> in the .evolution folder and .gconf folder.
> 
> However, I'm having the problem that .gconf/apps/evolution/mail/%
> gconf.xml is being reverted when evolution is started up.
> 
> I am stopping all evolution related processes, and all instances of
> gconfd-2 (if that one matters)
> I was told I need to stop gconftool-2, but that isn't running on my
> system.
> 
> What am I missing that causes the file to be reverted, or replaced with
> a "first run" version?

Use gconftool instead of hacking the files directly.  If you hack the
files directly, you are asking for trouble.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] segfault with evolution client functions and g_modules

[Ross Burton]

On Mon, 2007-09-10 at 22:30 +0200, Daniel Friedrich wrote:
> - opensync load the opensync-plugin with g_module_open()
> - than opensync execute a function of the opensync-plugin which execute
> the e_book_get_addressbooks() function
> - after that opensync unload the opensync-plugin with g_module_close()
> - when the program reaches the end (return of main) i get a segfault
> 
> Maybe the EDS client api uses the default g_main_loop and wants to
> execute some code while exiting the program. But at this point the
> plugin is already unloaded and the code not executable (SYMBOLS are
> unloaded). So it would be necessary to detach the EDS client from the
> g_main_loop. A finalize()-methode were great to do that.
> 
> I hope somebody can follow me and help to solve the problem.

libebook isn't designed to be loaded and unloaded, so it's best if you
don't even try to.  Even if there was a finalise() method, if you tried
to load/unload/load it will probably crash straight away as it tries to
re-register a supposedly static type.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] EDS API calls hang when EDS dies - how to detect that?

[Ross Burton]

On Sun, 2007-09-23 at 22:21 +0200, Patrick Ohly wrote:
> Looking at the current libebook API documentation [1] I see a
> "backend-died" signal prototype. I don't remember having seen that
> before - was the signal or its documentation added recently?

The documentation was likely added recently, the signal has existed for
a long time.

> I suppose I can call g_signal_connect(ebook, "backend-died", mycallback,
> NULL), then in mycallback print an error and abort the process, right?
> 
> Aborting the process is a very drastic reaction, it would be much nicer
> if e_book_get_contact() would return an error in that case. Can I
> achieve that by doing something in my code with the existing libebook
> shared objects shipped today?

Every blocking function should detect the backend crashing and return an
error message.  I'm not tremendously up to speed on the details of
Bonobo, but this should be a fairly simple patch.

I'll point out that the DBus port should handle this already. :)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Question about contact database content - contact UID

[Ross Burton]

On Fri, 2007-09-28 at 19:32 +0200, David Hautbois wrote:
> There is no good evolution python bindings to write in Evolution Data 
> Server.
> I only want to write contacts in the addressbook database directly.
> 
> So, I try to access to the addressbook database.
> I'm able to read and write in the database, but I've problems to create 
> valid contacts.
> 
> I just want to know how the UID field is built.
> 
> I've search in the libebook sources, but it's very difficult : I don't 
> know C.

Have you tried http://www.conduit-project.org/wiki/evolution-python?

You shouldn't access the database directly, because if someone is using
Evolution at the same time you'll corrupt the database.  Also, what if
the user doesn't have a local addressbook but is only using LDAP or
Groupwise?

Anyway, to answer your question, there is no set format.  EDS uses
pas-id-[some number], but the only requirement is that it is a unique
string.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Question about contact database content - contact UID

[Ross Burton]

On Fri, 2007-09-28 at 21:30 +0200, David Hautbois wrote:
> I just tried evolution-python.
> But it requires libebook >=1.80
> And on the Nokia N800, libebook = 1.4.2.1

The version numbers of libebook on the N800 don't really bare much
resemblance to reality, disable that check and it should work fine.  If
there are any errors they should be trivial to fix.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Synching Evolution/GNOME version

[Ross Burton]

On Wed, 2007-10-03 at 11:31 +, Srinivasa Ragavan wrote:
> There have been many requests regarding syncing the versions of
> Evolution (currently 2.12) and GNOME (2.20). I feel that it would be
> fine, if we just sync the minor versions. 
> 
> Evolution 2.22 
> GtkHTML 3.22
> Evolution Data Server 1.22
> Evolution Exchange 2.22

I'd like to see EDS synced completely to 2.22.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Synching Evolution/GNOME version

[Ross Burton]

On Thu, 2007-10-04 at 10:05 +0530, Srinivasa Ragavan wrote:
> Even I would have loved this if we can get all the friends to be 2.22.
> Unfortunately GtkHTML can't be 2.22 as it is already 3.xx. I felt that
> synchronizing the minor versions is fine. I'm not really against it, if
> there aren't any major objections to this.

I'm fine with GtkHTML being switched to 3.22, but I think it should be
the only exception, EDS should jump to 2.22.  No point not syncing it
entirely when its possible.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] When do I overwrite a server-side EContact?

[Ross Burton]

On Tue, 2007-11-13 at 15:51 +0100, Jules Colding wrote:
> On Tue, 2007-11-13 at 14:39 +0000, Ross Burton wrote:
> > On Tue, 2007-11-13 at 15:00 +0100, Jules Colding wrote:
> > > The create_contact() e-book function is rather loosely defined:
> > > 
> > > create_contact(EBookBackend *backend,
> > >  EDataBook *book,
> > >  guint32 opid,
> > >  const char *vcard)
> > > 
> > > 
> > > How would a backend know if an already existing contact entry should be
> > > overwritten with the new one?
> > 
> > If there is an existing contact with the same UID, create_contact fails.
> > Use modify_contact().
> 
> OK - How about the case where there is an existing contact that looks
> similar to the one that we attempts to create?

If it looks similar but is in all respects a different contact
(different UID, primarily), then you get two contacts.

EDS isn't the place for "this contact looks the same" logic, the UI is.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Ical (WebDAV) Web-Calendar read-only!?

[Ross Burton]

On Fri, 2007-11-30 at 12:49 +0100, Artur Mücke wrote:
> > I presume its using Webdav to write to the calendar file.  
> 
> Yes, your presumption is right because it is using WebDAV but I thought
> Evolution is doing the same, isnt it?

No, Evolution uses plain HTTP.

> > There are many problems with this approach including locking, concurrent 
> > writes,
> > and notification of changes.  However if you are the only person using
> > the remote calendar, it would work.
> 
> I dont know about that yet but I dont hope there are gonna be such
> problems because there will be more than 50 users using the OpenXchange
> server.
> 
> You scared me a bit with your statement. :-/

Unless there are extensions I'm not aware of, that sounds like its going
to break.  If both User A and User B edit the calendar, they will race
to write the changes.  The second person to write will replace the first
person's changes.

> However, we can outline that its definitely not possible to use WebDAV
> with Evoltion for writing/deleting appointsments if there is no support
> for CalDAV in OpenXchange!?

Evolution doesn't support using webdav for interactive editing of
calendars.  I think you can sync a calendar remotely using webdav, or
use caldav.

> Btw, thats really strange. What happenend to the project started in
> October 2005:
> http://www.open-xchange.org/pipermail/devel/2005-October/012704.html
> 
> I cannot find any result from this project!?

Ah, their webdav custom interface doesn't involve downloading and
uploading entire ical files.  This would need support in Evolution, and
I've no idea if there has been any progress.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Ical (WebDAV) Web-Calendar read-only!?

[Ross Burton]

On Fri, 2007-11-30 at 12:23 +0100, Artur Mücke wrote:
> Hmm, I dont know exactly about that, but e.g. in KDE-kontact I can use
> my  web-calendar like I want to. If I set it up with the same settings
> like in Evolution (https://IP-Address/servlet/webdav.ical). Its possible
> to create and delete appointsments in kontact without a problem.
> 
> How can that be!? I am really confused about that?

I presume its using Webdav to write to the calendar file.  There are
many problems with this approach including locking, concurrent writes,
and notification of changes.  However if you are the only person using
the remote calendar, it would work.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] evolution-data-server backend for using gmail contacts

[Ross Burton]

On Thu, 2008-01-03 at 21:26 +0100, Søren Boll Overgaard wrote:
> I've been looking around for any work on an evolution-data-server
> backend for loading gmail contacts in evolution. So far, all I've come
> up empty handed, except for http://www.go-evolution.org/EDS_Architecture
> which describes the evolution-data-server backends in semi-general
> terms.
> 
> Anyway, my question is, if anyone on the list is aware of any existing
> work on such a backend?

There is nothing for contacts as far as I know, but there is a calendar
backend which will probably provide a large amount of useful code
(specifically a gdata library).

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] massive e-d-s memory leak persuit ...

[Ross Burton]

Michael,

On Thu, 2008-01-24 at 17:46 +, Michael Meeks wrote:
>1666 -CONTACT-UID
>1666 -NAME
>1736 ION-DEST-NAME
>1894 OLUTION-BOOK-URI
>2100 -EMAIL
>2184 ION-DEST-EMAIL
>2318 OLUTION-FILE-AS
>2506 OLUTION-LIST
>2992 ION-LIST
>3058 comp
>3321 OLUTION-DEST-EMAIL
>3329 OLUTION-DEST-CONTACT-UID
>3993 OLUTION-DEST-NAME
>4534 pwise://[EMAIL PROTECTED]/;Novell GroupWise Address Book
>5343 BEGIN:VCARD
>5372 ION-DEST-EMAIL
>5504 END:VCARD
>5505 VERSION:3.0
>6786 ION-DEST-NAME
>8606 para
>   12739 ION-DEST-CONTACT-UID
>   13642 OLUTION-DEST-CONTACT-UID
>   18082 OLUTION-DEST-NAME
>   19252 OLUTION-DEST-EMAIL
>   21991 prop

The majority of those are from the contacts component, but because they
are truncated in some form I think they are left overs from previous
allocations.  I thought I'd fixed all of the major leaks in the
addressbook libraries, but maybe some new ones got introduced.  That
said the ATTENDEE field is from the calendar part, which I have never
really looked at.

If you can replicate this massive memory usage, could you run e-d-s in
massif?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] evolution-data-server addressbook backend

[Ross Burton]

On Tue, 2008-03-18 at 11:34 +0100, Matthias Braun wrote:
> I just started developing a custom addressbook(1) backend and have a few
> questions regarding the API. First I wonder about the functions
> get_contact_list, get_contact and get_changes. They don't seem to be
> used by evolution. Are there applications around that use them? Do bad
> things happen if I don't implement them (set the callback to NULL)?

Implement them.  Evolution doesn't use them as far as I know but
get_contact_list and get_contact will be used by other applications.
get_changes is used by syncing tools such as OpenSync.

> The other thing I can't get to work is authentication. If I abort an
> action with GNOME_Evolution_Addressbook_AuthenticationRequired then
> evolution is simply displaying me an error message. I would have
> expected that it asks me for username and password and calls the
> authenticate_user callback. How can I get this working?

To be honest I've only looked at the backends which don't require
authentication.  I suggest you read the LDAP backend.

At a guess, make you sure implement get_surpported_auth_methods.  Also
you'll want to call e_book_backend_notify_connection_status.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] encryption in evolution-data-server

[Ross Burton]

On Wed, 2008-03-19 at 11:39 +0800, liu shuai wrote:
> Every experts in evolution. I am very glad to be here to study some
> useful encryption in evolution-data-server.
> 
> Can you guide me the AES in libdb, or just share your knowledge of AES
> in evolution, or about the function of libdb? I am a new comer in
> evolution.

There is no encryption of data in Evolution Data Server.  If the data in
the libdb database was encrypted, it could still be captured whilst
being transferred to the client application.  With the DBus port this is
as trivial as running dbus-monitor, its trickier with the current ORBit
implementation but I suspect not that hard.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] encryption in evolution-data-server

[Ross Burton]

On Thu, 2008-03-20 at 17:35 +0800, liu shuai wrote:
> By the way, in the function sm_encrypt at
> "evolution-data-server/camel/camel-smime-context.c", I saw so many
> function like NSS_SMIMEUtil_FindBulkAlgForRecipients and so on. These
> functions seems no source code, and I can not understand what algorithms
> are used in the S/MIME. 
> 
> I do not know what algorithms are used for symmetric encryption and
> asymmetric encryption, and the specific signature algorithms? And
> whether the algorithms are implemented in the evolution, or they just
> call the external packages?

Camel uses NSS from the Mozilla project for encryption.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Issues in porting evolution mail client to directfb backend :Help Nedded.....

[Ross Burton]

On Mon, 2008-04-14 at 19:04 +0530, svalbard colaco wrote:
> I am trying to port evolution mail client to Directfb backend.
> 
> I have replaced X11 calls with  corresponding Gdk/Gtk function calls,
> found in evolution 
> and its dependent libraries so as to remove  linkage to xlib. 
> 
> Now  I can run the application  with DFB backend  but  when there is a
> requirement of 2/3
> windows(like Edit box,folder view  etc) to be displayed all together ,
> i am not able to see these together.
> 
> Also, Tool bar is not displayed properly , certain icons in the tool
> bar are missing.
> even while composing email _message_ edit_ box_ is missing.
> while configuring the email client,Preferences part is not working
> properly.
> 
> Pls give some pointers for the same. Any suggestion or Links in this
> regard will be of great help.

No need to post twice, remember that people often live in different
timezones.

You might just have a broken install of gtkhtml, which will make itself
obvious with errors on the console.  Alternatively you are probably
hitting widgets which use Bonobo, which as far as I'm aware uses widget
reparenting which will either never work or needs to be implemented on
DirectFB.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Issues in porting evolution mail client to directfb backend :Help Nedded.....

[Ross Burton]

Please reply to the list.

On Mon, 2008-04-14 at 20:04 +0530, svalbard colaco wrote:
> Thanx Ross for the input..
> 
> The following is the Debug Log on running evolutuionwill this
> be helpful??

> (evolution:32556): Bonobo-WARNING **: ARGH - different serious ORB
> screwup

Your Bonobo/ORBit is broken.  Whether this is due to a bad build, broken
configuration, or it just doesn't work on DirectFB, I don't know.

Ross

-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Issues in porting evolution mail client to directfb backend :Help Nedded.....

[Ross Burton]

On Tue, 2008-04-15 at 12:43 +0530, svalbard colaco wrote:
> As regard with the broken bonobo build..my make log /install log
> shows no errors.n gets built smoothly.. and even evolution
> runs but with many things missing in the UI as mentioned
> earlier...
> So i understand that this strikes out the possibility of a bad/broken
> build in bonobo..

Bonobo probably uses GtkPlug/GtkSocket, which have no implementation on
DirectFB.  I suggest you dig into bonobo to see if that is correct, and
then implement these (if possible at all).

> I wanted to Know what will be the implications of removing/decoupling
> bonobo from evolution package.
> Is it possble to replace Bonobo functionality by appropriate
> substitutes at the Gdk layer..

One of the long-term goals is to remove Bonobo entirely, but it's a lot
of work.  Your best bet is to add some debugging hooks into the stub
GtkPlug/GtkSocket source to see if they are being called, which would
explain your problem.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Removing libdb from EDS source

[Ross Burton]

Hi,

I think that we should remove the fork of Berkeley DB from the Evolution
Data Server source.  Debian, Ubuntu, Gentoo and Fedora all use
--with-libdb to dynamically link to a system library, so it is known to
work.

This would involve removing libdb from svn, and always dynamically
linking to libdb instead.  --with-libdb would still exist for people who
want to use a custom libdb, but it would default to /usr.

Thoughts?

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Loading of Icons in Evolution

[Ross Burton]

On Tue, 2008-05-13 at 18:16 +0530, svalbard colaco wrote:
> Can any one tell me where are the various icons (i.e. .png files )
> located in the code?
> i could find some icons in the following path
> 
> $PREFIX/share/icons/hicolor/24x24/stock/net
> 
> While some icon cannot be found...
> 
> Is there any way/ location in which the icons are loaded in Evolution?

Instead of saying "some", say what icon you can't find?  Icons used by
Evolution are generally either part of evolution, evolution-data-server,
or gnome-icon-theme.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Removing libdb from EDS source

[Ross Burton]

On Mon, 2008-05-05 at 10:58 +0530, Srinivasa Ragavan wrote:
> Ross, 
> 
> I had a chat with JP and He pointed me to a old README.
> 
> ===
> The issue was around no backwards compatability, from the old README:

In my experience recently Berkeley DB has been a lot more forgiving
recently.  Note that Debian links EDS against DB 4.5, and in the past
has linked against 4.4, 4.3, 4.2 instead of the EDS-bundled 4.1 without
any problems.

EDS has code to handle database upgrades if the file format does change.
Yes, this means that the user can't then use the same data file on
another machine if it uses an older DB version, but the DB file isn't
meant for interchange so I don't see this as a problem.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Fri, 2008-08-15 at 12:09 +0200, Muelli wrote:
> Hey :)
> 
> On 15.08.2008 12:01 [EMAIL PROTECTED] wrote:
> > The second approach would be writing
> > a DBUS interface to the e-d-s
> That has already been done: http://labs.o-hand.com/embedded-eds/
> 
> The problems are, as I was told, that it's pretty slow due to the 
> different API design. There is a lot of data being transferred forth and 
> back and D-Bus is not good in doing that. In order to take full 
> advantage of the D-Bus port, the e-d-s API would have to be redesigned. 
> But again, this is what I was told when I asked the same question. Other 
> may jump in and correct me where I'm wrong.

It's actually faster than EDS-ORBit.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Fri, 2008-08-15 at 12:59 +0200, [EMAIL PROTECTED] wrote:
> I may be wrong, but that is actually a port of EDS to use dbus, e.g.
> the user of the evolution data server, be it eds-dbus uses the same C
> API as eds-orbit. I'm actually talking more about doing a DBUS
> interface to the client C api, without actually touching eds.

A python wrapper around a DBus service which wraps a C library which
connects to a Bonobo service doesn't really sound like we're moving in
the right direction here.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Fri, 2008-08-15 at 13:40 +0200, Andre Klapper wrote:
> Am Freitag, den 15.08.2008, 11:17 +0100 schrieb Ross Burton:
> > On Fri, 2008-08-15 at 12:09 +0200, Muelli wrote:
> > > > a DBUS interface to the e-d-s
> > > That has already been done: http://labs.o-hand.com/embedded-eds/
> > > 
> > It's actually faster than EDS-ORBit.
> 
> Do we have stats, and also tests with addressbooks with, say, 300,000
> entries?

Benchmarks with 3000 contacts, yes, and it's faster in them all.  The
only address books with 300,000 entries are remote ones (LDAP, Exchange,
etc) and you can only search those, so then you're back down to
effectively <100 contacts.

> Two questions not necessarily aimed at Ross, and I remember asking this
> two years ago already:
> What's blocking/missing to get eds-dbus into 2.26?

More testing of the calendar port, porting of more backends (generally a
minute or so of work), and actually doing the merge.

> Can we agree on some plan to commit this into gnome's eds (if there's
> objections, then having optional support by some configure option) early
> in the next release cycle?

Rob Bradford and myself spoke about this at GUADEC.  Our basic plan to
propose to the Evolution community was to branch trunk in GNOME svn, and
merge the DBus port into it *replacing* Bonobo, instead of the current
approach of making DBus vs Bonobo a configure time option (which makes
several things more complicated).  The goal was to do this in time for
"GNOME 3.0".

> The impression of standstill annoys me.

And you are not the person who has been responsible for maintaining the
fork for three years. :)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Sat, 2008-08-16 at 19:20 +0200, [EMAIL PROTECTED] wrote:
>  Sorry for bugging you again but there is some stuff I would like to
> know. Is the e-d-s <--> libebook DBus interface good enough for
> scripting purposes (or is it documented somewhere so I can see it)?

No, I wouldn't call it good enough for scripting purposes, because
you'll need to provide your own vcard or icalendar parser/serialiser.
Also you'll need to know how the query language is expressed
(s-expressions) to do anything useful.  Unless you bring your own vcard
and icalendar parsers, and ask that the application developer writes
s-expressions themselves to search, you'll want more than a DBus
service.

Note that at present the DBus API isn't stable, so it can and does
change from time to time.  The interfaces are documented in svn, in
the .xml files in the libedata-(cal|book)-dbus directories.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Sun, 2008-08-17 at 10:01 +0200, Patrick Ohly wrote:
> On Sat, 2008-08-16 at 19:20 +0200, [EMAIL PROTECTED] wrote:
> > On Sat, Aug 16, 2008 at 1:32 PM, Ross Burton <[EMAIL PROTECTED]> wrote:
> > > This is DBus e-d-s:
> > >
> > > backends <-> e-d-s <== dbus ==> libebook <-> Evolution
> 
> The problem with this is that the synchronous API calls in libebook may
> fail due to DBus time outs when EDS responds to slowly. At least that
> was a problem that SyncEvolution on Nokia Internet Tablets ran into. My
> current workaround consists of overriding
> dbus_connection_send_with_reply() with my own version that uses a longer
> timeout than libdbus itself.
> 
> Ross, is this still an issue?

Yes, this is.  Methods which take that long to reply need to be
optimised so that they don't take forever to reply.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Sun, 2008-08-17 at 20:18 +0200, Patrick Ohly wrote:
> Do you plan to do that before replacing Bonobo in the mainline
> Evolution?

Yes, finding out why getchanges() is so damn slow is on the list of
things to do.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Tue, 2008-08-19 at 18:51 +0200, Patrick Ohly wrote:
> On Sun, 2008-08-17 at 19:30 +0100, Ross Burton wrote:
> > On Sun, 2008-08-17 at 20:18 +0200, Patrick Ohly wrote:
> > > Do you plan to do that before replacing Bonobo in the mainline
> > > Evolution?
> > 
> > Yes, finding out why getchanges() is so damn slow is on the list of
> > things to do.
> 
> I'm afraid speeding up the underlying C implementation in the file back
> end will only delay the inevitable: as the number of contacts grows,
> there'll always be a point when the time out strikes too early. It's
> simply not possible to squeeze an O(n) (or worse) implementation into a
> fixed amount of time in all cases :-/
> 
> Now in this case perhaps the implementation can be sped up so much that
> it doesn't matter. But in some other cases (backends which communicate
> with remote servers?) it will remain a problem.
> 
> IMHO the underlying problem is that Bonobo/ORBit/CORBA allow calls which
> run for an unlimited amount of time whereas DBus doesn't. Therefore a
> simple mapping of CORBA calls to synchronous DBus calls will always be
> problematic.
> 
> Do you think that mapping all synchronous libebook/libecal calls to
> asynchronous communication via DBus would be possible?

Any calls which can take longer than the DBus timeout and not be
considered to have a) serious implementation errors or b) timed out
remotely should be moved to method call -> signal pattern.

In the case of getChanges(), this is a local operation so just needs to
be fixed.  It shouldn't take more than the timeout, even with 10k
contacts.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Future of eds bindings

[Ross Burton]

On Wed, 2008-08-20 at 08:57 +0530, Srinivasa Ragavan wrote:
> Ross,
> 
> > In the case of getChanges(), this is a local operation so just needs to
> > be fixed.  It shouldn't take more than the timeout, even with 10k
> > contacts.
> > 
> 10K? I have seen multiple enterprise users books with 100K contacts. I
> remember some bug where the user had close to a million contacts :(,
> that might be GAL or GW System addressbook.

But do the GW or GAL backends implement getChanges()?  With that call
the number of changes is fairly unrelated to the number of contacts, so
it should always be fast enough.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Evolution: Taking forward...

[Ross Burton]

On Fri, 2008-07-11 at 04:21 -0600, Srinivasa Ragavan wrote:
> It would be really helpful if you can post a public/explicit mail with
> permissions to do it, or code pointers - if you think you wrote a
> piece of Evolution code & object.

Permission granted for any code I've produced.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Evolution: Taking forward...

[Ross Burton]

On Mon, 2008-09-15 at 12:35 +0100, Ross Burton wrote:
> On Fri, 2008-07-11 at 04:21 -0600, Srinivasa Ragavan wrote:
> > It would be really helpful if you can post a public/explicit mail with
> > permissions to do it, or code pointers - if you think you wrote a
> > piece of Evolution code & object.
> 
> Permission granted for any code I've produced.

(note that this is code I've personally produced.  Things like the DBus
port are LGPL2 at present and we'll have to work this out shortly)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory

[Ross Burton]

On Sat, 2008-09-20 at 09:55 +0200, Patrick Ohly wrote:
> On Sat, 2008-09-20 at 00:47 -0500, Hans Petter Jansson wrote:
> > Wouldn't it be possible to use a different directory, e.g.
> > "mail/local-index/folders.db"? That would avoid both problems.
> 
> Sounds very reasonable to me. Separating user data (mbox files) and meta
> data (indices) is much cleaner and simplifies things like backups of
> just the relevant data. See also the "Configuration masquerading Data"
> discussion on the Evo hackers list...

Starting to move cache and index files into ~/.cache/evolution would be
a good idea.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Importing contact from winME devices

[Ross Burton]

On Mon, 2008-09-22 at 09:59 +1200, Zainul Franciscus wrote:
> This is pretty straight forward. The only thing I have not figured out
> is how to generate a UID for the vcard. Does anyone know what is the
> algorithm that evolution mail to generate the UID ? Or even better is
> there an API that I can use to generate the UID ?

As long as it is unique, it doesn't matter.  EDS generates a unique
number from a number of sources,  but using a UUID would be fairly easy
and ensure that it is unique.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Status of the DBus port, future plans

[Ross Burton]

Hi,

As some of you may have noticed, there is a "dbus" branch in EDS now.
At present it contains a minimal port of the addressbook part of
eds-dbus to a fairly current (~1 week old) EDS tree.  This mostly works
and after a little cleanup should be ready for more testing.  However
there is a small problem with the calendar port which will take a bit of
explaining.

First an overview of some technical details as background.  The ORBit
addressbook and calendar have an "interesting" design which is as
follows.  The client makes one-way method calls to the server, which as
the name implies do not respond.  The server then makes one-way method
calls to a listener interface on the client, which then determines what
method call in the client this corresponds to.  The addressbook has
integer operation ids to do this, whereas the calendar code doesn't
allow simultaneous calls because it has the notion of a "current"
operation.  This isn't a great problem for the calendar, because the
only async method it has is open().

The thing is, this design has effected the design of libedata-cal.  The
DBus port uses a cleaner design of method calls having return values,
which thanks to DBus and dbus-glib is trivial to implement on both the
client and server.  The addressbook backends use the operation ID as a
entry into a hash table of DBus method contexts, but the calendar
backend API doesn't have anywhere to put the method context.

I'll cut to the chase.  This is an example of the current prototypes in
e-cal-backend.h, which is the interface backends (file, webcal, etc)
implement:

void e_cal_backend_get_object
(ECalBackend *backend, EDataCal *cal, const char *uid, const char *rid);

The current eds-dbus uses this:

void e_cal_backend_get_object
(ECalBackend *backend, EDataCal *cal, DBusGMethodInvocation *context,
const char *uid, const char *rid);

Note the addition of the DBus method context, so that the (potentially
much later) reply can be sent.  I'm going to change it to something like
this:

void e_cal_backend_get_object
(ECalBackend *backend, EDataCal *cal, EServerMethodContext *context,
const char *uid, const char *rid);

Where EServerMethodContext is an opaque pointer, so the backends can't
do anything with it apart from pass it back to the server.  Internally
it will remain a DBusGMethodInvocation*.


So, the gist of this rambling message is this: to merge the DBus port in
the current state I'd need to add a context argument to all of the
methods in e-cal-backend.  This will break API and I'll obviously be
fixing the backends which are shipped as part of EDS at the same time.
The good news is that the e-cal-backend-sync helper class effectively
shields users of that from the change, so this affects less backends
than you'd expect.

The alternative is to clone the ORBit API with DBus and use oneway
methods and the listener object.  This is substantial pointless
complication and won't allow us to add missing async versions of the
entire ECal API in the future, so I'm voting against this.

Any comments?

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Error Reporting in libebook

[Ross Burton]

On Fri, 2009-01-16 at 13:13 +0100, Matthias Braun wrote:
> I think it would be a good idea to have an additional API to report more
> details along the error messages. Do you agree with this? It's probably
> not optimal as you don't want translatable strings in evolution and
> can't even translate the messages returned by the server. I still think
> this would be way better than "Other Error".

The DBus port will allow the server to send textual messages along with
the code, which I'd like to expose in libebook.

Of course, if we're breaking API, then switching to GError would make
things a lot nicer.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Error Reporting in libebook

[Ross Burton]

On Mon, 2009-01-19 at 10:00 +0530, Srinivasa Ragavan wrote:
> Ross, didn't we break once before by stripping off some exposed bonobo
> stuff on the APIs ? So, is this new on the branch?

The removal of exposed Bonobo interfaces was strictly speaking an API
break but didn't effect anyone because the functions which were removed
from the public API were impossible to call from outside
libebook/libecal.

Adding GErrors to the client library would be a serious break for
clients, and something I'd personally defer until a full redesign of the
client APIs (something else I've been thinking about).

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Error Reporting in libebook

[Ross Burton]

On Mon, 2009-01-19 at 14:10 +0100, Mathias Hasselmann wrote:
> Some parts of the client API really need to be fixed. For instance
> currently EContact cannot work reliably as EVCardAttribute is mutable.
> Therefore you can change some contact attributes without EContact
> noticing it. World would be much better if EVCardAttribute would be
> immutable and if EVCard would have some virtual functions to inform
> subclasses like EContact about added/removed attributes.

I have a grand plan with very handwavy details which involves entirely
replacing EVCard and EContact, extending the views API, and sanitising
the book API.

My shorter-term task list includes reviewing the Maemo patches, because
yes this is a problem.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Coding style

[Ross Burton]

Hi,

Whilst working on the merge of eds-dbus I noticed again that the coding
styles in e-d-s are really mixed up.   What is the official coding style
(mainly indent size and tabs/spaces)?

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Branching for Evolution 2.28 on Aug 11

[Ross Burton]

On Tue, 2009-08-04 at 15:32 +0530, Chenthill wrote:
>   We have been waiting for a while to get the eds address-book dbus port
> merged into master for 2.28. Considering the stability issues we have at
> the moment with the branch (http://tinyurl.com/bgo-eds-dbus-hybrid ) and
> some work which needs to be done for evolution-exchange to work, we will
> be merging into master immediately after the branching for 2.28.

The dbus-hybrid branch has been merged into master now, this means that
EDS uses ORBit for the calendar and DBus for the addressbook.

There are a number of known bugs but if anyone finds any issues with the
addressbook, please file a bug!

My next goal is to get the calendar port ready for merging.  With any
luck this will be done this week.

Cheers,
Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] how to generate addressbook.db

[Ross Burton]

On Tue, 2009-08-25 at 08:27 +0800, Saint yeyo wrote:
> I wrote a code, that I called two function
> 'e_book_backend_file_load_source' and
> 'e_book_backend_file_create_contact
> then successful generate 'addressbook.db' and 'addressbook.db.summary'
> base on a exported vcard file,
> 
> then I tried copy the 2 generated addressbook.db into
> ~/.evolution/addressbook/local/system, then run evolution, click
> contact, but it told me can't load the file, I guess there are some
> different between my generate one with standard evolution generate,
> so, could you teach me how to generate standard addressbook.db file? I
> feel I mostly close my target, I will very appreciate for your help.

Instead of using ebookbackendfile directly just use libebook.
EBookBackendFile is an implementation detail and shouldn't be used
directly.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Can't find installed BookFactories

[Ross Burton]

On Wed, 2009-08-26 at 11:44 +0800, Saint yeyo wrote:
> when I tried libebook function such as : e_book_new,
> e_book_new_default_addressbook, e_book_new_system_addressbook to init
> a EBook, but all of them gave a error message: 
> WARNING **: Can't find installed BookFactories
> 
> 1.
>   EBook *n_ebook = e_book_new_system_addressbook (NULL);

If this gives an error message then your evolution-data-server or
ORBit/Bonobo installation is broken.

> 2.
>   vcf_file = "xxx.vcf";  // a exported vcard file from evolution
> directly
>   ESource *s_source = e_source_new_with_absolute_uri(vcf_file,
> dirname);
>   EBook *n_ebook = e_book_new (s_source, NULL);

vcf_file isn't a URI, so this won't work.

> 3.
>   EBook *n_ebook = e_book_new_default_addressbook (NULL);
> 
> 4.
>  const char *uri = "~/.evolution/addressbook/local/system";
>  EBook *n_ebook = e_book_new_from_uri  (uri, NULL);

Again, this isn't a URI.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] EDS DBus merge

[Ross Burton]

Hi,

I've just merged dbus-calendar into EDS, so we're now Bonobo-free in
evolution-data-server! There are several known regressions that I've
filed in bugzilla and will work on these shortly, although offers of
help are greatly appreciated.  Most of the major regressions are best
resolved via some refactoring, so fresh blood is welcome.

I've also renamed the status whiteboard flag to evolution[dbus] because
dbus-hybrid is incorrect now, so remember this tagging bugs!

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] MAPI support not even close... ?!?! Can I help?

[Ross Burton]

On Mon, 2009-11-30 at 14:42 -0500, Paul Smith wrote:
> Details: I'm running on Ubuntu 9.10 64bit.  I am building from the
> latest git master branch, updated as of this morning, for the
> following
> Gnome packages:
> evolution  evolution-data-server  evolution-exchange
> evolution-mapi  evolution-webcal  gtkhtml  libgweather
> libsoup
> libxml2 

Considering that e-d-s master has just been ported to DBus, and
evolution has just had Bonobo removed, I really recommend that you run
the gnome-2-28 branches of the GNOME modules.  Running master means you
acknowledge that stuff may well be broken, and the Evolution modules are
known to be broken (and being fixed) in lots of interesting ways.

Ross
-- 
Ross Burton mail: r...@burtonini.com
  jabber: r...@burtonini.com
   www: http://burtonini.com


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers