[Evolution-hackers] Unsubscribe
___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] modify the widget height
Dear All: Our project is planning to transplant the evolution to the low-cost PC, on which the screen resolution is 800*400. When the evolution starts, the widget of the main window and the assistant widget is out of the screen range, so I can't see the bottom of the widget and can't use the "OK", "forward","backward" button . I try to modify the source , but the source code is too big, I can't locate which c file can help me change the widget height. Can anyone give me a hand? Thanks. MARK ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Let the porting begin
On Thu, 2007-10-25 at 22:25 -0400, Jeffrey Stedfast wrote:
> On Fri, 2007-10-26 at 03:25 +0200, Philip Van Hoof wrote:
> > On Wed, 2007-10-24 at 11:58 -0400, Jeffrey Stedfast wrote:
> > > I took a look at the IDLE implementation last night and felt it went
> > > about it the wrong way.
> >
> > Yes, you are right. I think the right fix is to create a new API called
> > camel_tcp_stream_wait that works like this:
> >
> >
> > int bytes = camel_tcp_stream_wait (tcp_stream, stop_fd,
> > store->idle_sleep, line_buffer, 1023);
> [snip]
>
> I was thinking more along the lines of making the idle_loop use
> PRPoll()/poll() itself - it already has to figure out what type of fd to
> create for the cancel_idle_fd anyway.
I have it more or less working, with one more problem remaining (and I
already tried fixing it, check the "line_buffer" stuff in this patch)
being that the read returns me a block of bytes, not lines.
Yet I need to feed the rest of the current IDLE handling code exact
lines (untagged lines that start with '*').
So my plan is to use strrchr(buffer, '\n') and with the result calculate
where the last full line was. Then add that to what we stored last time.
And store the remainder in a buffer for the next loop.
Then with the two pieces together, strtok_r on \n and get the full lines
ouf of that.
I already started this, but I'm going to sleep now :)
Attached ... (it's again on Tinymail's trunk, not on Camel upstream)
> > Afaics It's not true that you don't need to change any API:
> >
> > The camel_stream_read() will block until all n bytes are read.
>
> no it doesn't. it returns as soon as any number of bytes are read or an
> error occurs.
>
> > This is
> > something you don't know during IDLE (how many bytes you can expect to
> > receive), and on top of that you want to continue immediately after
> > select returns, not keep retrying until you have n bytes (to simulate a
> > blocking read).
>
> sure, but that's why you poll yourself. once the socket has data, /then/
> you call camel_stream_read() on it.
>
> > You also want a dedicated stop fildescriptor, not the
> > standard cancel_fd as then any cancel will interfere with this (while
> > you want strict control over this to let other threads start and stop
> > IDLE).
>
> right, but if you add a CamelStream API, then you have to add 1 for unix
> fds and 1 for PRFileDesc
>
> plus it keeps the code simpler (keeps all read() logic in the
> camel_stream_read() implementations rather than duplicating it).
>
>
> This actually brings me to another thought I've had for a few years now
> but haven't bothered pushing for it... but it might be best if all of
> the sockets used PRFileDesc rather than unix fd for raw sockets and
> PRFileDesc for SSL sockets. If this is done, I think it'd be possible to
> get rid of CamelTcpStreamRaw and move the implementation into
> CamelTcpStream and make CamelTcpStreamSSL a simple subclass of
> CamelTcpStream, replacing the CamelTcpStream's PRFileDesc with an
> SSL-wrapped fd as appropriate and calling parent_class->read/write/etc
> instead of implementing them all itself /again/.
>
>
> Jeff
>
>
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
Index: libtinymail-camel/camel-lite/camel/providers/imap/camel-imap-store.c
===
--- libtinymail-camel/camel-lite/camel/providers/imap/camel-imap-store.c (revision 2884)
+++ libtinymail-camel/camel-lite/camel/providers/imap/camel-imap-store.c (working copy)
@@ -197,46 +197,31 @@
static void
let_idle_die (CamelImapStore *store, gboolean connect_buz)
{
-
- idle_debug ("let_idle_die starts\n");
-
- g_static_rec_mutex_lock (store->idle_prefix_lock);
g_static_rec_mutex_lock (store->idle_lock);
- store->idle_kill = TRUE;
- store->idle_cont = FALSE;
-
- if (store->idle_prefix)
+ idle_debug ("let_idle_die starts\n");
+ if (store->in_idle && store->idle_thread)
{
- gchar *resp = NULL;
- int nwritten = 0;
- CamelException ex = CAMEL_EXCEPTION_INITIALISER;
+ IdleResponse *idle_resp;
+ store->idle_cont = FALSE;
+ if (store->current_idle)
+ camel_operation_cancel (store->current_idle);
+ idle_resp = g_thread_join (store->idle_thread);
+ if (store->current_idle)
+ camel_operation_uncancel (store->current_idle);
- idle_debug ("Sending DONE in let_idle_die\n");
- CAMEL_SERVICE_REC_LOCK (store, connect_lock);
- nwritten = camel_stream_printf (store->ostream, "DONE\r\n");
store->in_idle = FALSE;
- if (nwritten != -1) {
- resp = NULL;
- while ((camel_imap_command_response_idle (store, &resp, &ex)) == CAMEL_IMAP_RESPONSE_UNTAGGED) {
-idle_debug ("(.., ..) <- %s | in let_idle_die\n", resp);
-g_free (resp); resp=NULL;
- }
- if (resp) {
-idle_debug ("(.., ..) <- %s\n", resp);
-g_free (resp);
- }
- }
- CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
- g_free (store->idle_prefix)
Re: [Evolution-hackers] Let the porting begin
On Wed, 2007-10-24 at 11:58 -0400, Jeffrey Stedfast wrote:
> I took a look at the IDLE implementation last night and felt it went
> about it the wrong way.
Yes, you are right. I think the right fix is to create a new API called
camel_tcp_stream_wait that works like this:
int bytes = camel_tcp_stream_wait (tcp_stream, stop_fd,
store->idle_sleep, line_buffer, 1023);
I need the amount of read-read bytes, to know where the buffer stops, so
I return it. I need a stop_fd to get the select() to early-stop. I need
a timeout for in case of connection problems. I need the buffer to put
the newly read data in and I need a size to tell it how large my buffer
max is.
.. idle_thread () ..
{
start_idle (store);
line_buffer = malloc (1024)
memset (line_buffer, 0, sizeof (*line_buffer));
...
while (store->idle_cont) {
char *lasts = NULL;
int bytes = camel_tcp_stream_wait (tcp_stream, stop_fd,
store->idle_sleep, line_buffer, 1023);
if (bytes > 0) {
char *resp;
line_buffer[bytes+1] = '\0';
for (resp = strtok_r (line_buffer, "\n", &lasts); resp; resp =
strtok_r (NULL, "\n", &lasts)) {
if (resp && strlen (resp) > 1 && resp[0] == '*') {
if (!idle_resp)
idle_resp = idle_response_new (folder);
consume_idle_line (store, folder, resp,
idle_resp);
lines++;
}
}
printf ("IDLE: read %d bytes %s\n", bytes, line_buffer);
}
if (!store->idle_cont || (idle_resp && idle_resp->exists_happened)) {
idle_done (store, folder, idle_resp);
stopped = TRUE;
if (!store->idle_cont)
retval = idle_resp;
}
if (store->idle_cont) {
if (idle_resp) {
process_idle_response (idle_resp);
idle_response_free (idle_resp);
idle_resp = NULL;
printf ("Processed %d lines\n", lines);
lines = 0;
}
if (stopped)
idle_start (store);
}
memset (line_buffer, 0, sizeof (*line_buffer));
}
}
That "wait" is implemented like this:
static ssize_t
stream_wait (CamelTcpStream *stream, int stop_fd, int timeout, char *buffer,
size_t max_len)
{
CamelTcpStreamRaw *raw = CAMEL_TCP_STREAM_RAW (stream);
int fd = raw->sockfd;
ssize_t nread;
int fdmax;
fd_set rdset;
u_long yes = 1;
struct timeval tv;
int res;
//ioctlsocket (fd, FIONBIO, &yes);
fdmax = MAX (fd, stop_fd) + 1;
FD_ZERO (&rdset);
FD_SET (fd, &rdset);
FD_SET (stop_fd, &rdset);
tv.tv_sec = timeout;
tv.tv_usec = 0;
nread = -1;
res = select (fdmax, &rdset, 0, 0, &tv);
if (res > 0 && !FD_ISSET (stop_fd, &rdset))
nread = recv (fd, buffer, max_len, 0);
else
nread = -1;
return nread;
}
Afaics It's not true that you don't need to change any API:
The camel_stream_read() will block until all n bytes are read. This is
something you don't know during IDLE (how many bytes you can expect to
receive), and on top of that you want to continue immediately after
select returns, not keep retrying until you have n bytes (to simulate a
blocking read). You also want a dedicated stop fildescriptor, not the
standard cancel_fd as then any cancel will interfere with this (while
you want strict control over this to let other threads start and stop
IDLE).
Well ... let me put it this way: I tried it from a few angles, I didn't
succeed with the normal camel_stream_read :-(
I have reworked the IDLE implementation. You can apply this patch to
Tinymail's upstream (trunk). You most likely can't apply it to upstream
Camel. (http://svn.tinymail.org/svn/tinymail/trunk)
There's still one problem: sometimes camel_imap_folder_stop_idle is not
returning late enough (the socket is still in IDLE state when it
returns).
Other than that, it usually works.
I'm trying to fix this last problem right now, and after that there will
most likely be a few days of testing before I put this in Tinymail's
repository.
> You should simply poll() on the socket descriptors (and a pipe fd used
> for telling the IDLE thread's I/O loop to finish and send DONE).
Yep
> Jeff
>
> On Mon, 2007-10-08 at 00:41 +0200, Philip Van Hoof wrote:
> > On Sun, 2007-10-07 at 14:15 +0200, Philip Van Hoof wrote:
> > > Hi there,
> >
> > > Using this changeset you can follow the changes to camel-lite:
> > >
> > > http://tinymail.org/trac/tinymail/changeset/2823
> > >
> >
> > This changeset are a bunch of compilation warnings for Matthew's Base64
> > patch to Camel: http://t
Re: [Evolution-hackers] [Evolution] Exchange MAPI Connector
On Tue, 2007-10-23 at 12:07 +0530, Srinivasa Ragavan wrote: > For Evolution 2.22 we should be having MAPI based Exchange connector > which developed in parallel with Openchange based libmapi. The team is > currently working on that and the code is currently maintianed at GNOME > SVN in EXCHANGE_MAPI_BRANCH (both for evolution and > evolution-data-server) This may be like the happiest news for quite a number of users.. Myself included. (Now.. if only it will work for the oulook web-based email like previously or be able to export/use RPC over HTTP) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] QRESYNC implementation for Camel-lite
On Thu Oct 18 00:41:39 2007, Philip Van Hoof wrote: > I implemented support for QRESYNC in Tinymail's camel-lite. I never > tested this because somehow the MBox copy that the friendly guys at > Isode gave me, is not starting up and I know of no other IMAP server > that already offers the QRESYNC capability. > > Thanks for the bragging-by-proxy. :-) I think we're the first to have a released product, but I'm not certain we're the only ones who've implemented it. Most of the other closed-source companies have much longer release cycles that we do. (We made 12 releases this year, and we're not slowing yet). We're certainly not the only ones to have things like CONDSTORE, which is much harder work, and gets both client and server 90% of the way there, so QRESYNC will probably start to appear soon. > I'll retry tomorrow after actually reading the documentation that > came > with it. > > Reading the docs? You're weird... > I'm for example not sure about the VANISHED reply (and the exact > meaning > of that "earlier" parameter). > > EARLIER indicates that the VANISHED response you're looking at doesn't refer to an event that's just occured, but to one (or lots) that occured at some unspecified point in time, probably when you weren't looking. To put it another way, these EARLIER ones are resynchronization data, and not event notifications. > ps. I added the nice folks at Evolution in CC, as some of these code > warriors are planning to migrate some of newer features in > camel-lite to > upstream camel. Hoorah - I know several people within Isode using Evolution who'll be happy at that. Feel free to bug me if there's anything I can do to help (test accounts, etc). Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange MAPI Connector
On Tue, 2007-11-20 at 23:48 +0530, Srinivasa Ragavan wrote: > Cody, > > You compiled from the branch? If so the provider/server type is > "Exchange MAPI". It is very much possible that the plugin is disabled in > your first time setups (Sorry these all are the bugs to be fixed). So > you create a dummy/local account and enable the plugin and create a new > account of type Exchange MAPI. I guess he just created an exchange owa account and not a MAPI thing. > > What is there in the branch is GAL/Contacts mostly works, Calendar > implementation is partial and folder list/summary is done and partial > mail fetch is there. > > -Srini. > > On Tue, 2007-11-20 at 09:38 -0600, Cody Ray wrote: > > I am compiling from svn just for this reason, but a strange thing is happening now and it may be due to permissions or something I am missing, but when I launch my freshly new compiled Evolution the Evolution Setup Assistant allows me to fill in name, org, email address, etc. and then I can choose my server type (I choose Exchange), but then I am unable to go forward as the Forward button is grayed out. Any ideas? Using Mint Linux with freshly checked out and compiled: > > > > evolution, evolution-caldav, evolution-data-server, evolution-exchange, evolution-gconf-tools, gtkhtml and libsoup. > > > > From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Holger Goetz [EMAIL PROTECTED] > > Sent: Tuesday, November 20, 2007 2:59 AM > > To: Srinivasa Ragavan > > Cc: evolution-hackers > > Subject: Re: [Evolution-hackers] Exchange MAPI Connector > > > > Hi Srini, > > > > thanks for the good news - no worries i don't blame anyone - i know how > > hectic dev can be ;-) > > > > Thanks,E > > Holger > > > > > > On Mon, 2007-11-19 at 23:12 +0530, Srinivasa Ragavan wrote: > > > Holger, > > > > > > I think by end of this week or so I should be able send out a > > > preliminary release with binaries as well. > > > > > > Don't blame me if I'm late. Things are really hectic here. > > > > > > -Srini. > > > > > > On Mon, 2007-11-19 at 15:35 +0100, Holger Goetz wrote: > > > > Hi, > > > > > > > > as i'm urgently waiting for a exchange 2007 enabled Evolution - is > > > > there any light on the horizon for preliminary version? - > > > > Actually a description on how to compile would be fine - Seems like > > > > specially the question about what libs (libmapi 0.6 and some samba4) > > > > need to be installed is important. As right now this kills all my > > > > tries to get a libmapi enabled version compiled out of the svn sources > > > > below... > > > > > > > > Thanks for any hints, > > > > Holger > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2007-10-23 at 12:07 +0530, Srinivasa Ragavan wrote: > > > > > Hello everyone, > > > > > > > > > > For Evolution 2.22 we should be having MAPI based Exchange connector > > > > > which developed in parallel with Openchange based libmapi. The team is > > > > > currently working on that and the code is currently maintianed at GNOME > > > > > SVN in EXCHANGE_MAPI_BRANCH (both for evolution and > > > > > evolution-data-server) > > > > > > > > > > http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/ > > > > > http://svn.gnome.org/viewvc/evolution-data-server/branches/EXCHANGE_MAPI_BRANCH/ > > > > > > > > > > I created the branch yesterday and we committed our week long effort > > > > > there. We now have a working account setup plugin, base camel/calendar > > > > > code and a partially working addressbook impl. Things should get to a > > > > > working shape in another week or two. I hope that soon, Johnny would be > > > > > able to create a OpenSUSE Build Service repository (rpms for OpenSUSE, > > > > > Fedora, Ubuntu and few more) for Evolution and its dependencies so that > > > > > users can install the rpms and get a feel of it even before the > > > > > release. > > > > > > > > > > -Srini.> > > > > Evolution-hackers@gnome.org > > > > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Sankar P Harver's Law: A drunken man's words are a sober man's thoughts Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e-book-backend-db-cache.[ch] - clearing?
Jules, I dont remember anything like that exists as of now. May be a crude way, but you can get the contacts and just unlink the db file. (I'm unaware of any consequences though). -Srini. On Tue, 2007-11-20 at 13:39 +0100, Jules Colding wrote: > Hi, > > Is there any way to unconditionally clear an e-book-backend-db cache > from all of its content? > > One could get all EContacts from the db and clear them one by one, but > that seems rather inelegant... > > > Thanks, > jules > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange MAPI Connector
Cody, You compiled from the branch? If so the provider/server type is "Exchange MAPI". It is very much possible that the plugin is disabled in your first time setups (Sorry these all are the bugs to be fixed). So you create a dummy/local account and enable the plugin and create a new account of type Exchange MAPI. What is there in the branch is GAL/Contacts mostly works, Calendar implementation is partial and folder list/summary is done and partial mail fetch is there. -Srini. On Tue, 2007-11-20 at 09:38 -0600, Cody Ray wrote: > I am compiling from svn just for this reason, but a strange thing is > happening now and it may be due to permissions or something I am missing, but > when I launch my freshly new compiled Evolution the Evolution Setup Assistant > allows me to fill in name, org, email address, etc. and then I can choose my > server type (I choose Exchange), but then I am unable to go forward as the > Forward button is grayed out. Any ideas? Using Mint Linux with freshly > checked out and compiled: > > evolution, evolution-caldav, evolution-data-server, evolution-exchange, > evolution-gconf-tools, gtkhtml and libsoup. > > From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Holger Goetz [EMAIL > PROTECTED] > Sent: Tuesday, November 20, 2007 2:59 AM > To: Srinivasa Ragavan > Cc: evolution-hackers > Subject: Re: [Evolution-hackers] Exchange MAPI Connector > > Hi Srini, > > thanks for the good news - no worries i don't blame anyone - i know how > hectic dev can be ;-) > > Thanks,E > Holger > > > On Mon, 2007-11-19 at 23:12 +0530, Srinivasa Ragavan wrote: > > Holger, > > > > I think by end of this week or so I should be able send out a > > preliminary release with binaries as well. > > > > Don't blame me if I'm late. Things are really hectic here. > > > > -Srini. > > > > On Mon, 2007-11-19 at 15:35 +0100, Holger Goetz wrote: > > > Hi, > > > > > > as i'm urgently waiting for a exchange 2007 enabled Evolution - is > > > there any light on the horizon for preliminary version? - > > > Actually a description on how to compile would be fine - Seems like > > > specially the question about what libs (libmapi 0.6 and some samba4) > > > need to be installed is important. As right now this kills all my > > > tries to get a libmapi enabled version compiled out of the svn sources > > > below... > > > > > > Thanks for any hints, > > > Holger > > > > > > > > > > > > > > > > > > On Tue, 2007-10-23 at 12:07 +0530, Srinivasa Ragavan wrote: > > > > Hello everyone, > > > > > > > > For Evolution 2.22 we should be having MAPI based Exchange connector > > > > which developed in parallel with Openchange based libmapi. The team is > > > > currently working on that and the code is currently maintianed at GNOME > > > > SVN in EXCHANGE_MAPI_BRANCH (both for evolution and > > > > evolution-data-server) > > > > > > > > http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/ > > > > http://svn.gnome.org/viewvc/evolution-data-server/branches/EXCHANGE_MAPI_BRANCH/ > > > > > > > > I created the branch yesterday and we committed our week long effort > > > > there. We now have a working account setup plugin, base camel/calendar > > > > code and a partially working addressbook impl. Things should get to a > > > > working shape in another week or two. I hope that soon, Johnny would be > > > > able to create a OpenSUSE Build Service repository (rpms for OpenSUSE, > > > > Fedora, Ubuntu and few more) for Evolution and its dependencies so that > > > > users can install the rpms and get a feel of it even before the > > > > release. > > > > > > > > -Srini. > > > > > > > > ___ > > > > Evolution-hackers mailing list > > > > Evolution-hackers@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange MAPI Connector
Hi, well i'm pretty sure you compiled successfully, but libmapi wasn't available in the proper version or form (that's what my original question was about). "Exchange" is the std. OWA based connector. Think it should be "Mapi" as server type. Check your configure logs from the build of evolution & evolution-data-server and you'll most probably find that libmapi wasn't found and there for disabled. I'd guess best for now is to wait until Srini gets through and drops something more complete ;-) Cheers, Holger On Tue, 2007-11-20 at 09:38 -0600, Cody Ray wrote: > I am compiling from svn just for this reason, but a strange thing is > happening > now and it may be due to permissions or something I am missing, but when I > launch my freshly new compiled Evolution the Evolution Setup Assistant allows > me to fill in name, org, email address, etc. and then I can choose my server > type (I choose Exchange), but then I am unable to go forward as the Forward > button is grayed out. Any ideas? Using Mint Linux with freshly checked out > and compiled: > > evolution, evolution-caldav, evolution-data-server, evolution-exchange, > evolution-gconf-tools, gtkhtml and libsoup. > > From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Holger Goetz [EMAIL > PROTECTED] > Sent: Tuesday, November 20, 2007 2:59 AM > To: Srinivasa Ragavan > Cc: evolution-hackers > Subject: Re: [Evolution-hackers] Exchange MAPI Connector > > Hi Srini, > > thanks for the good news - no worries i don't blame anyone - i know how > hectic dev can be ;-) > > Thanks,E > Holger > > > On Mon, 2007-11-19 at 23:12 +0530, Srinivasa Ragavan wrote: > > Holger, > > > > I think by end of this week or so I should be able send out a > > preliminary release with binaries as well. > > > > Don't blame me if I'm late. Things are really hectic here. > > > > -Srini. > > > > On Mon, 2007-11-19 at 15:35 +0100, Holger Goetz wrote: > > > Hi, > > > > > > as i'm urgently waiting for a exchange 2007 enabled Evolution - is > > > there any light on the horizon for preliminary version? - > > > Actually a description on how to compile would be fine - Seems like > > > specially the question about what libs (libmapi 0.6 and some samba4) > > > need to be installed is important. As right now this kills all my > > > tries to get a libmapi enabled version compiled out of the svn sources > > > below... > > > > > > Thanks for any hints, > > > Holger > > > > > > > > > > > > > > > > > > On Tue, 2007-10-23 at 12:07 +0530, Srinivasa Ragavan wrote: > > > > Hello everyone, > > > > > > > > For Evolution 2.22 we should be having MAPI based Exchange connector > > > > which developed in parallel with Openchange based libmapi. The team is > > > > currently working on that and the code is currently maintianed at GNOME > > > > SVN in EXCHANGE_MAPI_BRANCH (both for evolution and > > > > evolution-data-server) > > > > > > > > http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/ > > > > http://svn.gnome.org/viewvc/evolution-data-server/branches/EXCHANGE_MAPI_BRANCH/ > > > > > > > > I created the branch yesterday and we committed our week long effort > > > > there. We now have a working account setup plugin, base camel/calendar > > > > code and a partially working addressbook impl. Things should get to a > > > > working shape in another week or two. I hope that soon, Johnny would be > > > > able to create a OpenSUSE Build Service repository (rpms for OpenSUSE, > > > > Fedora, Ubuntu and few more) for Evolution and its dependencies so that > > > > users can install the rpms and get a feel of it even before the > > > > release. > > > > > > > > -Srini. > > > > > > > > ___ > > > > Evolution-hackers mailing list > > > > Evolution-hackers@gnome.org > > > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange MAPI Connector
I am compiling from svn just for this reason, but a strange thing is happening now and it may be due to permissions or something I am missing, but when I launch my freshly new compiled Evolution the Evolution Setup Assistant allows me to fill in name, org, email address, etc. and then I can choose my server type (I choose Exchange), but then I am unable to go forward as the Forward button is grayed out. Any ideas? Using Mint Linux with freshly checked out and compiled: evolution, evolution-caldav, evolution-data-server, evolution-exchange, evolution-gconf-tools, gtkhtml and libsoup. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Holger Goetz [EMAIL PROTECTED] Sent: Tuesday, November 20, 2007 2:59 AM To: Srinivasa Ragavan Cc: evolution-hackers Subject: Re: [Evolution-hackers] Exchange MAPI Connector Hi Srini, thanks for the good news - no worries i don't blame anyone - i know how hectic dev can be ;-) Thanks,E Holger On Mon, 2007-11-19 at 23:12 +0530, Srinivasa Ragavan wrote: > Holger, > > I think by end of this week or so I should be able send out a > preliminary release with binaries as well. > > Don't blame me if I'm late. Things are really hectic here. > > -Srini. > > On Mon, 2007-11-19 at 15:35 +0100, Holger Goetz wrote: > > Hi, > > > > as i'm urgently waiting for a exchange 2007 enabled Evolution - is > > there any light on the horizon for preliminary version? - > > Actually a description on how to compile would be fine - Seems like > > specially the question about what libs (libmapi 0.6 and some samba4) > > need to be installed is important. As right now this kills all my > > tries to get a libmapi enabled version compiled out of the svn sources > > below... > > > > Thanks for any hints, > > Holger > > > > > > > > > > > > On Tue, 2007-10-23 at 12:07 +0530, Srinivasa Ragavan wrote: > > > Hello everyone, > > > > > > For Evolution 2.22 we should be having MAPI based Exchange connector > > > which developed in parallel with Openchange based libmapi. The team is > > > currently working on that and the code is currently maintianed at GNOME > > > SVN in EXCHANGE_MAPI_BRANCH (both for evolution and > > > evolution-data-server) > > > > > > http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/ > > > http://svn.gnome.org/viewvc/evolution-data-server/branches/EXCHANGE_MAPI_BRANCH/ > > > > > > I created the branch yesterday and we committed our week long effort > > > there. We now have a working account setup plugin, base camel/calendar > > > code and a partially working addressbook impl. Things should get to a > > > working shape in another week or two. I hope that soon, Johnny would be > > > able to create a OpenSUSE Build Service repository (rpms for OpenSUSE, > > > Fedora, Ubuntu and few more) for Evolution and its dependencies so that > > > users can install the rpms and get a feel of it even before the > > > release. > > > > > > -Srini. > > > > > > ___ > > > Evolution-hackers mailing list > > > Evolution-hackers@gnome.org > > > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] e-book-backend-db-cache.[ch] - clearing?
Hi, Is there any way to unconditionally clear an e-book-backend-db cache from all of its content? One could get all EContacts from the db and clear them one by one, but that seems rather inelegant... Thanks, jules ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange MAPI Connector
Hi Srini, thanks for the good news - no worries i don't blame anyone - i know how hectic dev can be ;-) Thanks, Holger On Mon, 2007-11-19 at 23:12 +0530, Srinivasa Ragavan wrote: > Holger, > > I think by end of this week or so I should be able send out a > preliminary release with binaries as well. > > Don't blame me if I'm late. Things are really hectic here. > > -Srini. > > On Mon, 2007-11-19 at 15:35 +0100, Holger Goetz wrote: > > Hi, > > > > as i'm urgently waiting for a exchange 2007 enabled Evolution - is > > there any light on the horizon for preliminary version? - > > Actually a description on how to compile would be fine - Seems like > > specially the question about what libs (libmapi 0.6 and some samba4) > > need to be installed is important. As right now this kills all my > > tries to get a libmapi enabled version compiled out of the svn sources > > below... > > > > Thanks for any hints, > > Holger > > > > > > > > > > > > On Tue, 2007-10-23 at 12:07 +0530, Srinivasa Ragavan wrote: > > > Hello everyone, > > > > > > For Evolution 2.22 we should be having MAPI based Exchange connector > > > which developed in parallel with Openchange based libmapi. The team is > > > currently working on that and the code is currently maintianed at GNOME > > > SVN in EXCHANGE_MAPI_BRANCH (both for evolution and > > > evolution-data-server) > > > > > > http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH/ > > > http://svn.gnome.org/viewvc/evolution-data-server/branches/EXCHANGE_MAPI_BRANCH/ > > > > > > I created the branch yesterday and we committed our week long effort > > > there. We now have a working account setup plugin, base camel/calendar > > > code and a partially working addressbook impl. Things should get to a > > > working shape in another week or two. I hope that soon, Johnny would be > > > able to create a OpenSUSE Build Service repository (rpms for OpenSUSE, > > > Fedora, Ubuntu and few more) for Evolution and its dependencies so that > > > users can install the rpms and get a feel of it even before the > > > release. > > > > > > -Srini. > > > > > > ___ > > > Evolution-hackers mailing list > > > Evolution-hackers@gnome.org > > > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
