Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device

[Srinivasa Ragavan <sragavan gnome org>]

On Thu, Feb 2, 2012 at 2:49 PM, Michal G. <guziemic spam gmail com> wrote:
> Hi Srini,
>
> I will go in direction of modifying build process to be able to remove all
> dependencies to libraries that are not available on my SDK.
> I think it should be possible, but still I am not sure.
> My aim is to compile EDS (only mails) with Evolution (only libemail-engine +
> ??) and your e-mail-factory.
> Then I'm going to provide some GUI.
> Communication between those components should be done via DBUS.
> I am still no aware how content of mail will be visible for user. Or in
> other words, who will render its content.
>

Evolution uses gtkhtml for rendering mails. Anjal used webkit. You can
also use MozEmbed.

> In addition, I need to estimate how big package (backend) I will have after
> successful compilation.
> Could you help me in estimation?

Big in the sense size? I have no idea tbh.

-Srini
>
> Thanks in advance for advices.
>
> Michal
>
>
> On Tue, Jan 31, 2012 at 3:06 PM, Michal G. <guziemic spam gmail com> wrote:
>>
>> Hi,
>>
>> I tried to compile EDS with my SDK and unfortunately I did not success.
>> I run
>> autogen.sh --host=arm-oe-linux-gnueabi --enable-gtk-doc-html=no
>> --enable-goa=no --enable-nntp=no --disable-glibtest --disable-weather
>> and during checking of configuration following errors about missing
>> libraries occurs
>> - gtk+-3.0
>> - gmodule-2.0
>> - gconf-2.0
>> - libxml 2.0
>> - libsoup-2.4
>> - libgdata
>> - gio
>> - libdb
>> - and some other stuff related to NSS and NSPR.
>>
>> I removed all those checking from configuration.ac to be able to generate
>> Makefile.
>> Some of those libraries could be added to my system, but not all (for
>> instance gtk+).
>> Do you think that I will be able to compile EDS without gtk+?
>>
>> BTW, does 3.6 cycle should be release around September of 2012 or later?
>>
>> Michal
>>
>>
>> On Tue, Jan 31, 2012 at 10:46 AM, Srinivasa Ragavan <sragavan gnome org>
>> wrote:
>>>
>>> On Tue, Jan 31, 2012 at 3:00 PM, Michal G. <guziemic spam gmail com>
>>> wrote:
>>> > Hi,
>>> >
>>> > Nice to meet the author of Anjal :)
>>> >
>>> > I went through code and Wiki yesterday and I am starting to understand
>>> > just
>>> > a little piece of very high architecture.
>>> > I will try to compile EDS with my SDK for my ARM device. But first I
>>> > need to
>>> > familiarize with build process.
>>> >
>>> > As I understand within EDS there is mail engine - this Camel library
>>> > which I
>>> > could use and link dynamically with my GUI.
>>> > Do you know if there is simple example that shows how to send email
>>> > message?
>>>
>>> Camel is just the mail access/storage library. I meant
>>> libemail-engine.so in evolution/ project, which runs mails accounts,
>>> checks for mails etc.
>>>
>>> >
>>> > Probably better way will be to use your e-mail-factory. Then I will be
>>> > able
>>> > to split GUI and Mail engine on two different processes.
>>> > Will your e-mail factory be an official part of Evolution soon?
>>>
>>> e-mail-factory should be in eds in 3.6 cycle, but that depends on how
>>> much effort I get to merge evolution to use the mail daemon.
>>>
>>> >
>>> > I do not understand why you advice me to checkout branch of evolution.
>>> > I
>>> > thought that all data engines (mail and calendar) are covered by EDS.
>>>
>>> e-mail-factory needs libemail-engine, which is in evolution. Evolution
>>> needs EDS.
>>>
>>> > And when I compile it I will be able to connect it with my GUI. It
>>> > could be
>>> > done over DBUS if I have two processes or just dynamic linking to GUI.
>>> > Do I think correctly?
>>>
>>> You GUI should speak over dbus to the daemon (which is a process by
>>> itself) to fetch/access mails.
>>>
>>> >
>>> > Could you say, point me a document that describe how EDS store mails
>>> > and
>>> > calendar data. Is it some own database in file or some other mechanism?
>>>
>>> I don't remember any doc for this, what ever you find could be
>>> obsolete in some form I fear.
>>>
>>> -Srini
>>
>>
>