Re: [Evolution-hackers] Move evolution-alarm-notify to E-D-S?

2011-10-18 Thread Ross Burton
On 18 October 2011 17:52, Matthew Barnes mbar...@redhat.com wrote:
 Here's a crazy idea...

 What do you guys think about moving evolution-alarm-notify to E-D-S as a
 simple D-Bus service?  It could live in the new services directory:

    evolution-data-server/services/evolution-alarm-notify/

 evolution-alarm-notify is already an autostart program, launched when
 you start your desktop session, well before you ever launch Evolution.

 Problem is if it dies for some reason it has to be manually restarted,
 otherwise you'll miss appointment reminders.

Personally I'd prefer it if the logic in evolution-alarm-notify was
cleaned up into a library (I started this, see
https://github.com/rossburton/libealarm, but it needs a lot of work)
and then the GNOME Shell handle the notifications itself.  Currently
the notifications are pretty ugly and don't fit in with GNOME 3 at
all, which is a shame.  e-a-n should probably remain as an example and
for people who want Evolution 3 but not GNOME 3, but ideally won't be
used.

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] Google Tasks in EDS

2011-09-01 Thread Ross Burton
Hi,

Is anyone working on a Google Tasks backend for EDS?  Annoyingly
Google doesn't expose Tasks over CalDAV but they do have a custom
HTTP/OAuth/REST API that shouldn't be that hard to access from
librest.

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Google Tasks in EDS

2011-09-01 Thread Ross Burton
On 1 September 2011 08:15, Philip Withnall phi...@tecnocode.co.uk wrote:
 Any such backend would be best using libgdata to do the protocol-level
 work, since as you say, Tasks aren't exposed over CalDAV. This will
 require a new service to be added in libgdata:

As far as I am aware the Tasks API uses a custom JSON protocol[1],
whereas libgdata implements their GData extensions to Atom, which is
why I was suggesting json-glib+librest.

Ross

[1] http://code.google.com/apis/tasks/v1/reference.html#resource_tasks
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] GOA Integration (was: New 'eclient' branch in eds)

2011-06-30 Thread Ross Burton
On 30 June 2011 19:45, Matthew Barnes mbar...@redhat.com wrote:
 Once I can verify that it actually works I'll see if Dan's interested,
 although he did point me to librest, which is libsoup-based and provides
 more complete OAuth support than my little hack.

 http://git.gnome.org/browse/librest/tree/rest
 (can't find any online API docs for it)

Oh, I should sort that out.  librest has gtk-doc and almost reasonable coverage.

 It's looking like GLib might get HMAC support soon too, so we could sign
 tokens without liboauth's help.

librest does HMAC too, if you fancy copy-and-pasting some crypto code. ;)

I will pimp librest and say that if you have any questions about it, please ask.

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2011-05-13 Thread Ross Burton
On 12 May 2011 11:44, Patrick Ohly patrick.o...@gmx.de wrote:
 Can you perhaps comment? You wrote the TODO items below...
[snip]
 I can fix these TODOs. Any objections or concerns?

None whatsoever, those are embarrassingly leftin from the very early
porting where large chunks of code were copied from the contacts code
that just had an UID...

 It'll lead to a change of the D-Bus API. For master that shouldn't be
 a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I
 guess we have to bite the bullet and maintain a MeeGo version with a
 different API than regular 2.32.x.

I've always said that the DBus interface isn't a stable API and
shouldn't be trusted to remain constant.  If nobody else documented
that the DBus interface is stable then we shouldn't worry too much.
As a DBus API designed to be used by anything other than
libebook/libecal it's pretty dire.

 One more question about e_cal_backend_notify_object_removed(): it takes
 iCalendar 2.0 object strings as parameter in addition to the id. If both
 are set, it acts like object_updated. If the new object is NULL, it
 checks whether the old_object matches the view. Is that really
 necessary? There is a second check whether the ID is in the view in
 e_data_cal_view_notify_objects_removed():

 701             for (l = ids; l; l = l-next) {
 702                     ECalComponentId *id = l-data;
 703                     if (g_hash_table_lookup (priv-ids, id))
 704                         notify_remove (view, id);
 705             }

 At least that is my understanding. So is it afe to pass only the ID and
 old_object = object = NULL?

The logic there is probably mostly identical to the original logic in
the ORBit port, and the calendar side isn't something I'm
knowledgeable in...

That said the view checking seems to have been to ensure that you
don't get remove events for items you've never had.  As to the
semantics, I'd say if they are not documented make them reasonable and
document them. :)

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2011-05-13 Thread Ross Burton
On 13 May 2011 16:11, Patrick Ohly patrick.o...@gmx.de wrote:
 Did the previous code transmit UID+RECURRENCE-ID? I am wondering why
 Evolution manages to keep views properly in sync despite the lack of the
 RECURRENCE-ID - and what'll happen when it starts receiving them.

 I guess I'll find out...

I can't recall, sorry.  Time to get a checkout from before the DBus merge...

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] EDS improvements for MeeGo

2011-04-05 Thread Ross Burton
On 5 April 2011 10:21, Patrick Ohly patrick.o...@gmx.de wrote:
 I just noticed that e_book_get_book_view() already has a GList
 *requested_fields parameter. Is that used and/or implemented anywhere?

Not as far as I'm aware, no.

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Creating Evolution Memos from CLI/API

2010-09-20 Thread Ross Burton
On 19 September 2010 17:35, Kartik Thakore thakore.kar...@gmail.com wrote:
 I am attempting to make a bridge between tomboy and evolution. How can I
 add/edit/update/delete evolution memos from a CLI or API?

Use libecal.  Specifically e_cal_new and e_cal_open_async to open the
memos, e_cal_get_object, e_cal_modify_object, e_cal_remove_object to
get/update/delete memos, e_cal_component_* to modify memos,
e_cal_get_query to do a live query (i.e. you'll get notifications of
changes in Evolution) of the memos (recommended) or
e_cal_get_object_list_as_comp for a one-shot query.

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Creating Evolution Memos from CLI/API

2010-09-20 Thread Ross Burton
On 20 September 2010 07:07, Ross Burton r...@burtonini.com wrote:
 On 19 September 2010 17:35, Kartik Thakore thakore.kar...@gmail.com wrote:
 I am attempting to make a bridge between tomboy and evolution. How can I
 add/edit/update/delete evolution memos from a CLI or API?

 Use libecal.  Specifically e_cal_new and e_cal_open_async to open the
 memos, e_cal_get_object, e_cal_modify_object, e_cal_remove_object to
 get/update/delete memos, e_cal_component_* to modify memos,
 e_cal_get_query to do a live query (i.e. you'll get notifications of
 changes in Evolution) of the memos (recommended) or
 e_cal_get_object_list_as_comp for a one-shot query.

Oh and you'll probably want to look at e_cal_get_changes(), which lets
you get the changes notes since the last time you look.  Very useful
when combined with e_cal_query_objects() for syncing.

Ross
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data

2010-07-14 Thread Ross Burton
On Wed, 2010-07-14 at 17:37 +0530, chen wrote:
 ECalBackendSync - Abstract class from which you would need to subclass
 kolab backend. (http://live.gnome.org/Evolution/CalendarStore) 

Though only subclass this if you can't handle the async nature of the
ECalBackend API yourself.  Whether you subclass ECalBackend or
ECalBackenSync is a choice made by how the backend will be implemented.

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
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data

2010-07-14 Thread Ross Burton
On Wed, 2010-07-14 at 20:14 +0530, chen wrote:
  Though only subclass this if you can't handle the async nature of the
  ECalBackend API yourself.  Whether you subclass ECalBackend or
  ECalBackenSync is a choice made by how the backend will be implemented.
 Is this used by any backends or will be used ? I was just having this
 question while reading through the go-evolution.org link.
 ECalBackendSYnc  adds the notification to the clients for the sync calls
 made by the clients through libecal, which anyways cant be ignored isn
 it ? So usage of ECalBackend functions for sync calls such as,
 e_cal_backend_create_object, get_object, get_object_list etc. just adds
 extra work of notifying the clients using e_data_cal_notify*.
 
 If the answer is, they are not used, better to mark them as deprecated
 and cleanup this area. ECalBackend can then just be used for Async apis
 like,
 e_cal_backend_notify_object_(added, modified, removed) and future
 free/busy async apis etc.

But if your backend can make async calls (say you implement it using
GIO) then you can drop the BackendSync layer and notify yourself.  One
of my plans was to move the each operation in a thread logic into
E*BackendSync because asynchronous backends obviously don't need to be
in a thread.

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
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Base URI for On This Computer

2010-06-09 Thread Ross Burton
On Wed, 2010-06-09 at 08:56 -0400, Matthew Barnes wrote:
 but since they have to change anyway, I propose just naming it:
 
 local://unique-id

local:unique-id, surely.  No need for // when you're not putting a
hostname or path.

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
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] edbus branch review ...

2010-02-27 Thread Ross Burton
On Fri, 2010-02-26 at 22:31 +, Michael Meeks wrote:
   Thoughts / flameage ? :-)

My thoughts are woohoo and great work.  If I'm feeling brave on
Sunday I'll start a clean build of eds and evo-edbus and dogfood it.

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] Moving from the single mbox file format for the local folders

2009-12-16 Thread Ross Burton
On Wed, 2009-12-16 at 16:54 +0530, Srinivasa Ragavan wrote:
  I definitely won't switch away from maildir as my format of choice
  because it integrates nicely with offlineimap.
 
 Sure, I think users should have that freedom. Camel's local folder
 implementation has that built in. This new approach should be the
 default for new users, and as option for users to migrate to it for
 existing users. If users willingly stay with maildir or
 1mbox-per-folder that should also be there.

I don't really see the point of inventing a new file-per-message format
when maildir already exists, is already implemented in evolution (albeit
buggily), and is a very popular format.  NIH seems a bit pointless
really.

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?

2009-12-04 Thread Ross Burton
On Thu, 2009-12-03 at 16:12 -0500, Reid Thompson wrote:
 (evolution:24437): libebook-WARNING
 **: ../../../../evolution-data-server/addressbook/libebook/e-book.c:2194: 
 cannot activate book: The name org.gnome.evolution.dataserver.AddressBook was 
 not provided by any .service files 

You installed evolution-data-server into a prefix that DBus doesn't know
about, so it can't autostart the daemons.

I have this in my /etc/dbus-1/session.conf:

  servicedir/home/ross/BUILD/share/dbus-1/services//servicedir

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?

2009-11-30 Thread 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


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

2009-08-26 Thread 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


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

2009-08-25 Thread 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] Branching for Evolution 2.28 on Aug 11

2009-08-17 Thread 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


[Evolution-hackers] Coding style

2009-06-01 Thread 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] Error Reporting in libebook

2009-01-21 Thread 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


Re: [Evolution-hackers] Error Reporting in libebook

2009-01-19 Thread 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

2009-01-16 Thread 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] Importing contact from winME devices

2008-09-22 Thread 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


Re: [Evolution-hackers] Future of eds bindings

2008-08-17 Thread 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

2008-08-15 Thread 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

2008-08-15 Thread 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] Removing libdb from EDS source

2008-06-13 Thread 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] Loading of Icons in Evolution

2008-05-13 Thread 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] Issues in porting evolution mail client to directfb backend :Help Nedded.....

2008-04-15 Thread 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


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

2008-04-14 Thread 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.....

2008-04-14 Thread 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] encryption in evolution-data-server

2008-03-20 Thread 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] massive e-d-s memory leak persuit ...

2008-01-24 Thread 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 backend for using gmail contacts

2008-01-03 Thread 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] Ical (WebDAV) Web-Calendar read-only!?

2007-11-30 Thread 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!?

2007-11-30 Thread 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] When do I overwrite a server-side EContact?

2007-11-13 Thread Ross Burton
On Tue, 2007-11-13 at 15:51 +0100, Jules Colding wrote:
 On Tue, 2007-11-13 at 14:39 +, 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] Synching Evolution/GNOME version

2007-10-04 Thread 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] Synching Evolution/GNOME version

2007-10-03 Thread 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] Question about contact database content - contact UID

2007-09-28 Thread 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

2007-09-28 Thread 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] EDS API calls hang when EDS dies - how to detect that?

2007-09-23 Thread 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] segfault with evolution client functions and g_modules

2007-09-10 Thread 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] Data storage question

2007-08-09 Thread 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] XML APIs in evolution

2007-05-30 Thread 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] Removal of implementation details from public API, any breakages?

2007-05-21 Thread 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 bonobo/bonobo-object.h
 #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


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

2007-05-20 Thread 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?

2007-05-20 Thread 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] Addressbook Maintainership

2007-05-18 Thread 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] Lonely patches waiting review

2007-05-01 Thread 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


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

2007-04-04 Thread 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


Re: [Evolution-hackers] libebook scalability

2007-04-02 Thread 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

2007-04-02 Thread 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

2007-04-02 Thread 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

2007-04-02 Thread 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


Re: [Evolution-hackers] Minimize to Systray

2007-04-01 Thread 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] e_contact_set() and IM fields

2007-03-19 Thread 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] evolution-data-server/calendar/libical and SVN

2007-01-02 Thread 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


[Evolution-hackers] Removing code duplicated in GLib

2006-12-08 Thread 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] RFC: Evolution's library requirements

2006-12-05 Thread 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


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

2006-11-30 Thread 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] Adding documentation to Evolution's code

2006-08-11 Thread 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

2006-08-11 Thread 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] Error while trying to obtain ESource list

2006-07-26 Thread 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] Camel in evolution-data-server, a different proposal

2006-07-22 Thread 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] Camel in evolution-data-server, a different proposal

2006-07-13 Thread 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

2006-07-13 Thread 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


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

2006-07-12 Thread 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

2006-07-12 Thread 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] strtok camel from evolution-data-server

2006-07-07 Thread 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 libedataserver/e-data-server-util.h
#include libedataserver/e-iconv.h
#include libedataserver/e-memory.h
#include libedataserver/e-msgport.h
#include libedataserver/e-sexp.h
#include libedataserver/e-time-utils.h
#include libedataserver/e-trie.h
#include libedataserver/md5-utils.h

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

2006-07-07 Thread 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


[Evolution-hackers] Directory structure re-organisation

2006-07-03 Thread 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] building evolution-data-server against the already installed libdb

2006-03-06 Thread 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] Announce : Evolution 2.5.92, EDS1.5.92, Evolution-exchange 2.5.92 and Gtkhtml 3.9.92

2006-03-01 Thread 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] ... and how camel should be

2006-02-14 Thread 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] Re: Questions about merging evo/e-util/e-util.c into e-d-s/libedataserver/e-util.c?

2005-12-21 Thread 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] Feedback from Slashdot

2005-12-07 Thread 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

2005-12-07 Thread 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] About evolution-data-server/libedataser and evolution/e-utils

2005-11-28 Thread 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

2005-11-28 Thread 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] About evolution-data-server/libedataser and evolution/e-utils

2005-11-24 Thread 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

2005-11-24 Thread 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

2005-11-24 Thread 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] standalone e-d-s

2005-09-20 Thread 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] freeing evolution data structures

2005-09-12 Thread 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