Re: [Evolution-hackers] Move IMAPX back to a module library for 3.12
On Mon, Aug 19, 2013 at 9:03 PM, Matthew Barnes wrote: > The IMAPX classes were moved into Camel's public API to serve as base > classes for evolution-kolab. But since Christian has parted ways with > us it would appear the evolution-kolab project is no longer active. > > I'm planning a good deal of API changes to IMAPX over the next few > months as I work toward completing IMAP NOTIFY support, and I would > prefer these changes not be seen as breaking Camel's public API so I > have sufficient freedom to change what needs changed. > > Therefore I plan to move the IMAPX classes back to a runtime-loadable > module library after the 3.10 release. If the evolution-kolab project > is resurrected at some point in the future then we can renegotiate this. > > Any objections? I still dont accept it under Camel. Since we are fixing it, Im fine. -Srini. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, Jul 24, 2013 at 3:28 PM, David Woodhouse wrote: > I don't think that makes sense. As Fabiano points out, Evo and EDS are > *very* closely tied. Even in the *stable* branch in 3.8.4 there are > fixes for EDS/EWS which require corresponding fixes in Evo. > > Breaking the close version ties with the rest of GNOME makes sense, but > not between Evo and EDS. It is my wish, we could decouple EDS & Evolution releases to start building API/ABI stability into EDS. I don't have strong objects to EDS having yearly releases. Im not saying that we wont/cant' to backporting fixes and re-releasing for minor/micro releases. We should be able to go back at least 2 GNOME releases. This is required kind of required if you want to avoid 'adapting to 3.6 EDS' like commits in EWS/LibreOffice/SyncEvolution/* -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Hi Fabiano, On Wed, Jul 24, 2013 at 6:29 AM, Fabiano Fidêncio wrote: > Srini, > > >> I really wouldn't want EDS to be part of this, if we ever want it to >> be a proper platform/core material. Just Evolution would be better fit >> for this model IMHO. > > Could I ask you why? > If you check our git's activity you will see that the most part of > bugs we are fixing are touching both in Evolution as in EDS. > I really cannot imagine these two parts not walking together. I know how tight the development is. Infact, in my watch, we added a configure check that mandates same minor & micro version. But IMHO this model should change for good. It kind of brought lot of flexibility for introducing breakages because we know Evolution would work with only the right version of EDS well but we kind get into a model of ignoring the apps that would depend on EDS. All along we (Evolution/EDS hackers) were blamed for breaking API/ABI. Im not support this following statement, but there was a time, when you can just build evolution and not use latest EDS/Gtk/other platform bits on atleast 2 older GNOME releases. I may not ask for this, but atleast we should have EDS decoupled from Evolution releases to let it survive/develop as a platform on its own. Some might argue that having a yearly releases will give longer API/ABI stability, but again coupling EDS & Evolution will let us into more breakages. My point for this was not about the duration, but about decoupling the EDS & Evolution releases to plan/avoid any API/ABI (re)designs for EDS. This is my thought, and some may support it but a lot might oppose it ;-). Thanks, -Srini. > > Best Regards, > -- > Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, Jul 23, 2013 at 7:40 PM, Matthew Barnes wrote: > I've been kicking around this idea for awhile now, but haven't said > anything until now. I'm putting it out there as food for thought. > > Increasingly I'm feeling like the traditional 6-month release cycle is > just too short for Evolution. In terms of development, we have a pretty > short window for landing major changes and allowing adequate time for > testing before development freezes set in. I like the idea very much and had similar plans before, but never went forward with it before. > > But more importantly, our users seem to be constantly playing catch-up > in terms of supported releases. Because of the delay between upstream > releases and distro releases, by the time users finally upgrade to a > newer Evolution, more often than not they're upgrading to a version > that's either nearing the tail end of its 6-month support window or is > already unsupported. > > That's frustrating, both for users and for me as a developer, but we > just don't have the manpower to support multiple stable releases and > still get any kind of significant development work done. > > I'd like us to consider moving to a 12-month release cycle, which would > sync up with GNOME's release schedule annually instead of semi-annually. > > Here's my initial proposal, if you guys are open to this: > > * Continue with the 6-month releases through the end of the year, just > because I think we need more lead time for such a major policy change. > > * Bump Evolution's major version number to split away from GNOME's > semi-annual release numbering. Call the upcoming March 2014 release > Evolution 4.0 (or perhaps even Evolution 2014... I'm open to ideas). > > * We would follow GNOME's string change announcement and freeze schedule > in the months leading up to each March release. > > * We would continue releasing stable updates and development snapshots > at a steady pace. Our release schedule could even be more predictable > than it is now. We could do, for example, stable releases on the 1st > Monday of each month and development snapshots on the 3rd Monday. > The challenge will be to sync properly with the GNOME freezes during the second half of the cycle. It will be good to sync with that, so that when the product releases with GNOME release, there is doc / translation all ready. I really wouldn't want EDS to be part of this, if we ever want it to be a proper platform/core material. Just Evolution would be better fit for this model IMHO. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What happened to email-factory?
[Sorry, I was away on a family emergengy and just back to work] On Sat, Jan 5, 2013 at 6:28 PM, Matthew Barnes wrote: > On Fri, 2013-01-04 at 20:58 +0200, Mehmet Giritli wrote: > > I was looking forward to have the email backend moved into EDS so that I > > can write a proper mail notification UI for gnome. But I noticed that > > the branch here https://github.com/sragavan/e-mail-factory was never > > merged and I can no longer see it among the future plans. So I am a > > little curious what happened to this project? Has it been dropped > > entirely? > > Good question. I'd still like to see it happen, but I haven't heard > from Srini in several months and our architecture has changed greatly > since the last commit on that repo. If I end up having to carry it the > rest of the way then it then it's at least a year out yet since I have > other priorities. This is a nice-to-have, not a must-have feature. > I haven't ported it beyond 3.4. But I always see a week or two effort to update to the latest branch. Evolution project exports the libemail-engine and libemail-utils (which is gone now) to e-mail-factory daemon[1]. I just keeping porting it when I get sometime. Its definitely not dead and I wouldn't leave it atleast. The daemon code[1] is maintained here for the time being once we do all great, this & the library should be in EDS. It has a complete dbus api but the ideal design would be to get a eclient based one. It needs about 4-6man months to complete this and let evolution use this. -Srini [1] - https://github.com/sragavan/e-mail-factory ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit branch is ready
On Wed, Mar 28, 2012 at 4:13 PM, Daniel Vratil wrote: > Hello everyone! > > WebKitGtk+ 1.8.0 with the important patch has been released last night, and > so everything is in place now and I'm ready to break^W merge to master. The > branch has been rebased two days ago, I will only bump the webkit dependency > version later today. > > I hereby ask you guys for review and approval for the merge. This is great news. Im just so excited to try things out for 3.5.x. Do you have webkit for composer too? -Srini. > > I'd suggest creating 4 or 5 new commits directly in master instead of actual > git merge to avoid polluting master history with nearly 200 commits of my > furious development :) > > Cheers, > > Dan > ___ > 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 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] Rethinking account management
On Thu, Mar 1, 2012 at 8:13 PM, Matthew Barnes wrote: > I added a page to our wiki about the upcoming file format for account > data. It focuses more on the nuts and bolts of the file format itself > rather than the APIs used to access the data. In particular, I wanted > to get the mail account format written down somewhere since it's a bit > more complex than the rest. > This is good to have. Lemme go through them to see if I see any issues there -Srini. > http://live.gnome.org/Evolution/ESourceFileFormat > > Matthew Barnes > > ___ > 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 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] Compile Evolution Mail as .so file with API for other GUI on ARM device
Hi Michal, On Thu, Feb 9, 2012 at 2:27 PM, Michal G. wrote: > Hi, > >> If you are looking to get eds/evo rid of gtk, you are proned to be >> lost. Instead, use the dbus api and write a email client in qt. You >> can glance it https://meego.gitorious.org/meego-ux/meego-app-email. I >> worked on a qt/qml based email client which spoke to the email daemon >> over dbus. It is obsolete atm. > > > Thanks for help. I look at this code and it is very interesting from my > point of view. It is very close > to this what I am trying to achieve. I am not going to use Qml, but I can > take it as an example My purpose for showing the code is to look at it as an example :) > and develop my own app. As I saw Qml is related with Qt QMF component. > From Qt Labs description it sounds like very useful framework. > Does it means that this application is using Evolution only to store mails > and all > connection with mail servers (POP, IMAP, SMTP) is handled by QMF? > The code I showed you, uses e-mail-factory for everything. It replaced QMF. > Could you tell me if meego-app-calendar is done in similar way? > http://meego.gitorious.org/meego-ux/meego-app-calendar > > As I saw both projects do not have any activity in last days. Do you know if > those projects are still alive or maybe developed as closed-code? The code is dead, I dont have any closed source on them. I have no idea on the calendar stuff. Sorry. -Srini ___ 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] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Mon, Feb 6, 2012 at 8:18 PM, Michal G. wrote: > Hi, > > I need more support as Evolution is huge project and I feel that I am lost. > Last days, I just went through code and I compiled EDS but on X86 without > Gtk+. > Thus, I modified some configuration files and main makefile to be able to > compile. > > Next, I tried to compile Evolution. But there is a lot of dependencies to > UI (gtk), > which I would like to remove. I would like to replace it for instance with > GUI > written in Qt. If you are looking to get eds/evo rid of gtk, you are proned to be lost. Instead, use the dbus api and write a email client in qt. You can glance it https://meego.gitorious.org/meego-ux/meego-app-email. I worked on a qt/qml based email client which spoke to the email daemon over dbus. It is obsolete atm. > > I have question regarding functionality and place where should I look for > source code. > I think that main components on which I should focus are following folders > - libemail-utils > - libemail-engine > - mail (I am not sure if I should consider this folder) > > and there is folder modules/mail - what kind of functionality is kept there? Its for the UI of evolution & its logics. -Srini > > Is there other place where code related to email is located? > > And does Evolution uses system settings for network configuration as default > or > it must be configured somehow? > > Michal ___ 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] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Thu, Feb 2, 2012 at 4:11 PM, Michal G. wrote: > Then I will use Webkit. It is available and I was doing simple browser with > it. > For now, I have Qt port of Webkit and Cairo graphic. > > Regarding size, I wonder about footprint of Evolution. I checked on my > Ubuntu and > it is about 12 MB. Hopefully it will required less space after removing of > some parts. > > I found also some interesting post about EDS. > http://mail.gnome.org/archives/evolution-hackers/2011-June/msg00028.html > As I understand there is some work done to make EDS more UI independent. > Do you know if this was done, or work is in progress and in which release it > will be? CamelSettings is done. But Im not sure of what you mean by UI independence. > > And as release 3.4 is planned for March 2012. Does it means that 3.6 should > be available after > six months, so around September 2012. Does evolution follows GNOME schedules > (new stable version every six months)? Yes. Evo follows GNOME schedules. -Srini > > Michal > > > > On Thu, Feb 2, 2012 at 10:21 AM, Srinivasa Ragavan > wrote: >> >> On Thu, Feb 2, 2012 at 2:49 PM, Michal G. 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 > > ___ 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] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Thu, Feb 2, 2012 at 2:49 PM, Michal G. 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. 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 >> wrote: >>> >>> On Tue, Jan 31, 2012 at 3:00 PM, Michal G. >>> 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 >> >> > ___ 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] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Tue, Jan 31, 2012 at 3:00 PM, Michal G. 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 > > Michal > > > > On Mon, Jan 30, 2012 at 3:37 PM, Srinivasa Ragavan > wrote: >> >> Hi >> >> On Mon, Jan 30, 2012 at 6:27 PM, Michal G. >> wrote: >> > Hi, >> > >> > Thank you for answer. >> > >> > Yes. I'm looking for mail engine that will be able to communicate for >> > instance over DBUS which some UI. >> > My device does not uses X.org, GTK and Cairo. >> > It future, I would also append my software with Calendar functionality. >> >> Calendar is already in EDS available over DBUS. >> >> > >> > I choosed to work with Evolution because I saw similar email client >> > called >> > Anjal that utilize Evolution but has own UI. >> >> I was the author of Anjal. It was build with Gtk/Cairo on top of >> libevolution-mail. Now after mbarnes's awesome library breaks, I broke >> mail engine to a independent library that can reside in EDS (in the >> future) which I currently server over DBUS. >> >> You must checkout master branch of eds and evolution. >> https://github.com/sragavan/e-mail-factory is the dbus engine that Im >> working on, which is still under development. Some apis are fun and >> still not up to the mark. But you can use them and it works fine. >> >> -Srini. >> >> > >> > Could you tell me from which git should I clone >> > - http://git.gnome.org/browse/evolution-data-server >> > - http://git.gnome.org/browse/evolution >> > >> > And could you tell where to start, or what should I read some to >> > - build mail engine library (http://mad-scientist.us/evolution.html - >> > should >> > I follow this process) >> > - API of DBUS >> > >> > Michal >> > >> > >> > On Sat, Jan 28, 2012 at 7:35 AM, Srinivasa Ragavan >> > wrote: >> >> >> >> Hi Michal, >> >> >> >> On Fri, Jan 27, 2012 at 5:27 PM, Michal G. >> >> wrote: >> >> > Hi, >> >> > >> >> > I've been investigating a possibility of Evolution Mail >> >> > cross-compilation >> >> > for Linux X-less device (ARM) and use it as dynamic library that will >> >> > provide me possibility to expose API that could be utilize by HMI >> >> > layer. >> >> > >> >> > 1) Is it possible to compile Evolution Mail without any user >> >> > interface >> >> > (pure –headless)? Or how much work would that require? >> >> > 2) Does Evolution architecture allows doing such split – mail >> >> > supporting >> >> > functionality and GUI? >> >> > 3) Is it possible to eliminate all unnecessary libs and resources? >> >> > They’re using val
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
Hi On Mon, Jan 30, 2012 at 6:27 PM, Michal G. wrote: > Hi, > > Thank you for answer. > > Yes. I'm looking for mail engine that will be able to communicate for > instance over DBUS which some UI. > My device does not uses X.org, GTK and Cairo. > It future, I would also append my software with Calendar functionality. Calendar is already in EDS available over DBUS. > > I choosed to work with Evolution because I saw similar email client called > Anjal that utilize Evolution but has own UI. I was the author of Anjal. It was build with Gtk/Cairo on top of libevolution-mail. Now after mbarnes's awesome library breaks, I broke mail engine to a independent library that can reside in EDS (in the future) which I currently server over DBUS. You must checkout master branch of eds and evolution. https://github.com/sragavan/e-mail-factory is the dbus engine that Im working on, which is still under development. Some apis are fun and still not up to the mark. But you can use them and it works fine. -Srini. > > Could you tell me from which git should I clone > - http://git.gnome.org/browse/evolution-data-server > - http://git.gnome.org/browse/evolution > > And could you tell where to start, or what should I read some to > - build mail engine library (http://mad-scientist.us/evolution.html - should > I follow this process) > - API of DBUS > > Michal > > > On Sat, Jan 28, 2012 at 7:35 AM, Srinivasa Ragavan > wrote: >> >> Hi Michal, >> >> On Fri, Jan 27, 2012 at 5:27 PM, Michal G. >> wrote: >> > Hi, >> > >> > I've been investigating a possibility of Evolution Mail >> > cross-compilation >> > for Linux X-less device (ARM) and use it as dynamic library that will >> > provide me possibility to expose API that could be utilize by HMI layer. >> > >> > 1) Is it possible to compile Evolution Mail without any user >> > interface >> > (pure –headless)? Or how much work would that require? >> > 2) Does Evolution architecture allows doing such split – mail >> > supporting >> > functionality and GUI? >> > 3) Is it possible to eliminate all unnecessary libs and resources? >> > They’re using valuable device resources and may cause compilation >> > problems. >> > 4) If I’m about hacking the build process to my needs (removing >> > dependencies) where should I start? >> >> IIUC you want to use the engine of evolution, but not the UI. If so, >> I've been working on a mail daemon which has all the mail logic built >> in and exposes mail (basic) interface over dbus. If you aren't >> interested in that, you can look at libemail-engine.so which is a new >> library that I added a week ago in master which provides most of what >> you are looking at except the UI. >> >> -Srini >> >> > >> > Best regards, >> > Michal Guzieniuk >> > >> > >> > ___ >> > 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 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] Compile Evolution Mail as .so file with API for other GUI on ARM device
Hi Michal, On Fri, Jan 27, 2012 at 5:27 PM, Michal G. wrote: > Hi, > > I've been investigating a possibility of Evolution Mail cross-compilation > for Linux X-less device (ARM) and use it as dynamic library that will > provide me possibility to expose API that could be utilize by HMI layer. > > 1) Is it possible to compile Evolution Mail without any user interface > (pure –headless)? Or how much work would that require? > 2) Does Evolution architecture allows doing such split – mail supporting > functionality and GUI? > 3) Is it possible to eliminate all unnecessary libs and resources? > They’re using valuable device resources and may cause compilation problems. > 4) If I’m about hacking the build process to my needs (removing > dependencies) where should I start? IIUC you want to use the engine of evolution, but not the UI. If so, I've been working on a mail daemon which has all the mail logic built in and exposes mail (basic) interface over dbus. If you aren't interested in that, you can look at libemail-engine.so which is a new library that I added a week ago in master which provides most of what you are looking at except the UI. -Srini > > Best regards, > Michal Guzieniuk > > > ___ > 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 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] wip/settings branch is merged
On Wed, Nov 23, 2011 at 7:44 PM, Matthew Barnes wrote: > On Wed, 2011-11-23 at 16:05 +0530, Srinivasa Ragavan wrote: >> I rebased email-factory-3-4 branch of evolution on top of gsettings >> merge. I'm away for a week in Finland, hopefully you get time to merge >> this around :-) > > Okay, thanks. I'll be traveling too for the next couple weeks. Working > off and on, won't be on IRC much. But I'll try to look at this next. > Thanks, I probably want to get to the API in C and then start with evolution migration. This merge will help me let go of the engine and focus on further things. Thanks, -Srini ___ 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] Camel no longer depends on libedataserver
On Tue, Nov 15, 2011 at 10:03 AM, Matthew Barnes wrote: > I have severed all of Camel's remaining dependencies on libedataserver, > mostly by way of code duplication. In particular, all of Camel's search > and filtering code now uses CamelSExp, which is a clone of ESExp. > > libcamel now builds first in the evolution-data-server module, and its > pkg-config file has shed its libedataserver-1.2 requirement. You should > consider it a base library for E-D-S, like libsoup or libgdata. > > There is no longer any _technical_ reason why Camel needs to be bundled > in the evolution-data-server module. I DO intend to split Camel off at > some point, but not yet. Parts of its API are still a complete mess and > I'd like to give them some attention and also reach some semblance of > API stability for the library as a whole. We're not there yet. When I complete my branch & merge mail to EDS, more of mail code is gonna end up there (of course, its atleast one more release away). I don't see a chance of camel being missed out there ;-) -Srini ___ 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] Move evolution-alarm-notify to E-D-S?
On Tue, Oct 18, 2011 at 10:22 PM, Matthew Barnes 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. > > My thought was if it also claimed a well-known session bus name then it > could easily be activated by evolution-calendar-factory on start up, and > (most importantly) RE-activated if the calendar factory detects that the > bus name lost its owner. I like the idea. It might also be great, if it can notify across the bus for alarms so that any third party program can listen and operate upon. -Srini ___ 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] WebKit port progress update
On Sat, Aug 27, 2011 at 11:38 PM, Matthew Barnes wrote: > On Sat, 2011-08-27 at 09:26 +0530, Srinivasa Ragavan wrote: >> One thing I can say is that, this will be faster than the earlier >> method, for reason that even when we expand one attachment/mail, we >> rerender the entire mail and remember their previous states etc which >> is sort-a ugly. This approach only deals with the MIME part that you >> expand/hide and very simple and fast. > > Well the current approach of making the attachment button and the > attachment itself two separate embedded widgets is suboptimal. I know > GtkHtml doesn't handle resizing embedded widgets very well so maybe it > was done that way as a workaround? > > Assuming WebKit is better at resizing embedded widgets, an easier > approach is to pack each button/attachment pair into a vbox and bind the > button's "expanded" state to the lower widget's "visible" state. Then > you just have to embed one vbox per attachment, which should hopefully > avoid having to redraw the whole email when expanding an attachment. Right, but I doubt it. When I did for anjal, I had to make webkit expand every time. It otherwise draws a scrollbar around it even when you have space to expand. Not sure if things have improved lately. You need to write some test code to confirm before you start up the design. -Srini. > > ___ > 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 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] WebKit port progress update
On Fri, Aug 26, 2011 at 10:02 PM, Matthew Barnes wrote: > On Fri, 2011-08-26 at 17:20 +0200, Dan Vratil wrote: >> as I already mentioned on the IRC meeting, embedding widgets into WebKit >> is broken and I was told that WebKit-Gtk developers intend to drop this >> functionality sooner or later. > > Citation needed. Xan Lopez said he wasn't aware of any problems or > plans to drop the API when I asked him about this after the IRC meeting, > and the bug you opened includes a comment with a possible solution: > > https://bugs.webkit.org/show_bug.cgi?id=63451 > > >> So I decided to go similar way Anjal >> does, splitting the email display into multiple webviews. To be able to >> do so, I also decided to change the way EMFormat works as well. > > IIRC, Srini told me told me at the Boston Summit last year that this > approach for Anjal was fine for display but derailed when it came time > to print. > > > Maybe Srini can comment further? (CC'ing him) > It isn't simple for printing. But you can work it around by supporting only the needed file types. In any case see if we can get a top window cairo handle and print it to a printable surface. It should be much easier and match what the user sees. If we can do anjal like webkit rendering, it is very simple to get a conversation view into evolution. I could pull pieces from anjal and build it for evolution. [...] > Don't get me wrong, the design you're proposing sounds sensible _if_ you > can overcome the printing issue. I'm just pointing out the known speed > bumps on this road. > This is the most appropriate approach I felt for anjal, since Webkit then didn't have embedded gtk objects. IIRC newer webkit supports it. Worth a try to see if it is feasible to consider that. One thing I can say is that, this will be faster than the earlier method, for reason that even when we expand one attachment/mail, we rerender the entire mail and remember their previous states etc which is sort-a ugly. This approach only deals with the MIME part that you expand/hide and very simple and fast. -Srini ___ 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] Rethinking Camel settings
Hi Matthew, On Thu, Jun 9, 2011 at 10:37 PM, Matthew Barnes wrote: > I'm at the point now with the account-mgmt branch where I have to deal > with the settings that trickle down into the various Camel providers. > The way the settings are managed now is to embed them into the Camel > service's URL string as a list of named parameters. This is suboptimal > for the same reasons as the free-form ESource "property" dictionary: > > - All settings have to be manually converted to/from a string, even if > it's a numeric or boolean value. This is more of a nuisance than a > blocker. > > - No way to query all available settings in a given CamelService > instance, since some parameters may be omitted from the URL string. > > - No way to query the default values for these settings, which is > important for things like the mail account editor. Assuming FALSE > or NULL or 0 in the absence of a parameter isn't always correct. > > - No nice way to push change notifications for these settings down > to Camel. In most cases an app restart is required. That may be > unavoidable for some settings, but we can do better overall. > Everything sound pretty sane to me. Looking forward to these changes soon. I'd also love to see a updated doc about how things were and how they are now (or atleast a doc about how things are now). I would move the e-mail-factory from the 2.32 code base to 3.3 once you land all these stuffs. I'm looking forward to merge the code in that timeframe. Will help me a lot to refine the dbus apis. Thanks, -Srini. ___ 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] CamelService changes
On Fri, Apr 22, 2011 at 5:54 PM, Matthew Barnes wrote: > On Fri, 2011-04-22 at 11:02 +0530, Srinivasa Ragavan wrote: >> Mostly sounds fine to me as a complete picture, but do remember of >> the email-factory branch that I'm working on to run mail on EDS. >> >> I now expose an API (and some custom bits) over dbus that corresponds >> to camel's session/store/folder. >> >> http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-session.xml?h=email-factory >> http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-store.xml?h=email-factory >> http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-folder.xml?h=email-factory >> >> It'd be great if you can finalize on the API soon, which can help me >> move things from 2.32 to master. But for now, I'm mainly on the 2.32 >> branch to get a stable state of the engine. > > Can you please provide some kind of summary of the design you have, > either here on the mailing list or on a wiki page, since as far as I > know no one else has a good idea of what you're doing or how it works. > > I've been trying to get everyone to do this when making large changes, > so that no one is working away in secret and suddenly shows up with what > they think is a finished product. Oh sure, http://wiki.meego.com/Architecture/planning/evolution-data-server/email-design has some high level design/architecture of the daemon. It also has details on the way MeeGo app uses it and some task list. But The high level design/architecture of the daemon is up there. -Srini. > > ___ 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] CamelService changes
Hey Matt, On Thu, Apr 21, 2011 at 10:13 PM, Matthew Barnes wrote: > To help smooth the way for the account-mgmt I've made a few improvements > to the CamelSession and CamelService APIs in 3.1. It's not necessarily > the *final* APIs that will wind up in 3.2, but more like the first round > of changes leading up to 3.2. > > * Every CamelService instance now has a unique ID string. This will now > be the primary way of identifying CamelServices, rather than comparing > URL strings. > > * Adding new services to the CamelSession and retrieving services from > the CamelSession are now distinct operations, replacing the "create on > demand" approach of the past. > > camel_session_add_service() is a new method that takes a UID string, a > CamelURL, a CamelProviderType and a GError and tries to instantiate a > new CamelService instance for the information given. > > camel_session_get_service() now simply takes a UID string, and is a > straight-forward hash table look up. It no longer references the > returned CamelService, so you don't need to unreference it. > > * CamelService now implements the GInitable interface, and can fail on > instance creation. This replaces its construct() method. > > * The file storage location for CamelServices (really only CamelStores) > has changed. It is now simply: > > $(XDG_DATA_HOME)/evolution/mail/$(UID) > > rather than: > > $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) > > That means each CamelService has a permanent location for files that > doesn't change if the user tweaks server settings or even changes the > provider. > > CamelService will handle the migration itself during instance creation > by reconstructing the old directory path, testing for existence, and > if found, renaming the directory to the new form. > > This solves bug #546491 and also means we won't be leaving so much > junk behind over time in the user's data directory. It will also make > it easier to clean up after ourselves when accounts are deleted. > > * The UIDs given to CamelServices are taken from EAccounts. But because > an EAccount describes both a store and transport but has only one UID > string, the CamelStore for the EAccount gets the UID string verbatim > and the CamelTransport for the EAccount gets the UID + "-transport". > It's a bit of a kludge for now, but will be cleaned up when the > account-mgmt branch lands. > > * For built-in CamelStores, the UID for the "On This Computer" store is > "local", and the UID for the "Search Folders" store is "vfolder". For > now these are just hard-coded names. > > The changes are behaving well for me so far, but I imagine I probably > broke a corner case or two in some provider somewhere. Let me know if > you see anything amiss. Mostly sounds fine to me as a complete picture, but do remember of the email-factory branch that I'm working on to run mail on EDS. I now expose an API (and some custom bits) over dbus that corresponds to camel's session/store/folder. http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-session.xml?h=email-factory http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-store.xml?h=email-factory http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-folder.xml?h=email-factory It'd be great if you can finalize on the API soon, which can help me move things from 2.32 to master. But for now, I'm mainly on the 2.32 branch to get a stable state of the engine. -Srini. > > ___ > 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 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] [Fwd: [MeeGo-dev] migration (back) to EDS]
On Tue, Mar 22, 2011 at 2:14 AM, Matthew Barnes wrote: > On Mon, 2011-03-21 at 15:50 +0100, Patrick Ohly wrote: >> If you see some increased interest in EDS soon, then it might be because >> MeeGo is currently investigating how to use EDS as the main PIM and >> email system again. >> >> Attached a rough outline of the current ideas. My expectation is that we >> will start sharing more thoughts and questions here as we proceed. >> >> Note that this work probably has to be delivered to MeeGo as part of an >> Evolution 2.32 based solution, because I don't see us moving to 3.0 soon >> enough. > > Hey Patrick, thanks for the info. > > I meant to ask you when last we spoke on IRC, to what extent are you > involved with MeeGo right now, and is there anyone else specifically on > the MeeGo team that we should be reaching out to? I'm trying to get a > feel for who all is or is going to be involved. Hey Matt, I'm part of the team that is working on it. I'll catch you on IRC asap to discuss very specific details. -Srini. > > ___ > 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 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] [Reminder] Evolution community meeting at #evolution-meet channel - Aug 18 - 3:30 PM UTC
On Mon, Aug 16, 2010 at 6:54 PM, chen wrote: > On Mon, 2010-08-16 at 18:20 +0530, Srinivasa Ragavan wrote: >> On Mon, Aug 16, 2010 at 6:00 PM, chen wrote: >> > Hi, >> > This is first meeting after our GUADEC 2010! There would be some >> > interesting updates during meeting. The meeting goes as follows, >> >> It probably should be Aug 18 :-) > Thanks for correcting. /me tells to himself - either dont copy paste or > make the template dynamic :) Time to use the 'Templates' evolution plugin ;-) -Srini. > > - Chenthill. >> >> -Srini. >> >> > >> > * Project updates >> > * Discussion on queries/decisions >> > * Individual updates >> > >> > - Chenthill. >> > >> > ___ >> > 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 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] [Reminder] Evolution community meeting at #evolution-meet channel - July 18 - 3:30 PM UTC
On Mon, Aug 16, 2010 at 6:00 PM, chen wrote: > Hi, > This is first meeting after our GUADEC 2010! There would be some > interesting updates during meeting. The meeting goes as follows, It probably should be Aug 18 :-) -Srini. > > * Project updates > * Discussion on queries/decisions > * Individual updates > > - Chenthill. > > ___ > 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 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] [Reminder] Evolution community meeting at #evolution-meet channel - July 14 - 3:30 PM UTC
On Tue, Jul 13, 2010 at 11:07 AM, chen wrote: > Hi all, > Our this month's community meeting happens on July 14th. This would > be the community meeting before GUADEC 2011!! Isn't this supposed to be GUADEC 2010? ;-) -Srini. > > Post any queries to the list today if you want them to be answered in > the community meeting. Gives some thinking time for all the people for a > fruitful discussion. > > I will add a link to the wiki for the community meetings to collect the > questions for the forth coming meetings. > > Query from me for this meeting to discuss: > + Having evolution-collab-backends to hold all collab backends ? > > - Chenthill. > > ___ > 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 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] Evo and Kolab2 - a fresh attempt
On Wed, May 26, 2010 at 2:45 PM, Christian Hilberg wrote: > Hi Matthew, > > On Tuesday, 25 May 2010, you wrote: >> Hi Christian, >> This sounds pretty cool and would be a welcome addition to the Evolution >> suite. > > Good. :) > >> On Tue, 2010-05-25 at 19:29 +0200, Christian Hilberg wrote: >> > [...] >> I know of no other active Evolution/Kolab2 project at the moment. > > Well, then we're good to go. > >> [...] >> We prefer backends for groupware servers to be packaged as a standalone >> extension module for Evolution. See for example evolution-exchange and >> evolution-mapi (and I believe the GroupWise backends will soon be split >> off similarly). > > Thanks for the hint. We'll try it that way then. Look at MAPI design. Its way of organizing code, cache handlers which are good. Groupwise tbh wasn't designed/written the best possible way or it was done when the infrastructure was just being developed in parallel. -Srini. > >> > QA is one of the topics which will be stressed, so I was checking how >> > unit testing is done within Evolution. Skimming through the sources of Evo >> > 2.28.3, I found that there does not seem to be the "one specific way" of >> > doing testing, hence I would be interested in getting to know whether >> > there is a preferred way of doing (unit) testing. >> We are woefully lacking an actively maintained and comprehensive unit >> test suite and I don't think the project has yet matured to the point >> where we even -have- a unit testing preference. I'd recommend looking >> to the broader GNOME community for best practices. > > We'll check that out with other Gnome projects. It may take some more research > on the project itself before we know how to actually accomplish the testing > stuff. My thoughts atm tend towards cunit/expect and/or the GLib testing > framework. We'll check which method will impose the least impact in respect to > dependencies. Let's see whether there is some gnomish/gtk'ish/GLib'ish way of > doing testing which will be fitting for an Evo extension. > >> Mainly I think you want to integrate the tests into your autotools >> framework (assuming that's what you're using) so the tests are executed >> by running "make check" or "make distcheck". In addition, GLib offers >> some basic utilities for constructing test fixtures, though I'm not sure >> to what extent that API has really caught on yet. > > autotools, 'make check' and friends will be the road to take, as far as I can > see right now. We'll take a closer look at the GLib testing framework to see > how much usable it is already. > >> > Connecting Evo and Kolab2 will most likely involve rather heavy use of >> > LibCamel infrastructure. Which Evolution version we will concentrate on >> [...] >> > versions of Evo which should later be ported painlessly to newer >> > versions of Evo. It would be great to be pointed into the right >> > directions here. >> I'd strongly recommend targeting at least version 2.30, and if you're >> that heavy on Camel and can withstand a little API churn, 2.31 would be >> best so that you're using GObject from the get go. Version 2.30 of both >> Evolution and E-D-S was such a significant step forward from previous >> releases that I've come to regard it as a generation gap. Targeting a >> release from an earlier generation will likely mean more pain down the >> road when you finally have to cross that gap. > > Hopefully, it will be possible for us to do it that way. We have just begun > our evaluation process, so lets see. Using the GLib'ified Evo code right from > the start would be wise. Anyway, we'll have to check whether we can afford > using Evo 2.30 / 2.31 as a code basis for our project... > >> It's true that libcamel's backward compatibility guarantees have been >> temporarily withdrawn until its API is sufficiently modernized. The API >> changes for 2.31 should taper off within the next month or so, then pick >> up again once libgio gains support for transport layer security. >> I'm guessing the Camel upgrades will be mostly complete by Evolution 3.2 >> next spring (assuming TLS support lands on schedule), and thereafter API >> and ABI stability will be restored. > > Phew, that's quite some time down the road. Our project is scheduled to show > usable results (i.e. installable packages which work as expected) within this > year. That means we might have to use a current stable version of Evo for now. > OTOH, it is also no fun to raise a project which is obsolete-by-design. We'll > have to meditate on that. > > Thanks for taking time to give us some useful hints! We'll be around. > > Best regards, > > Christian > > > -- > kernel concepts GbR Tel: +49-271-771091-12 > Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 > D-57072 Siegen Mob: +49-176-21024535 > http://www.kernelconcepts.de/ > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsu
Re: [Evolution-hackers] Access Contacts information from Remote Machine with Python
On Fri, Dec 25, 2009 at 4:27 PM, Michael Pilgermann wrote: > Dear List Members, > > for a PIM synchronization program called PISI, which we mainly develop for > the Linux Phone Freerunner, I am currently trying to implement Evolution > connectivity - starting up with the contacts domain. > > The basic concept is to run PISI on the mobile phone Freerunner using a > network connection tunneled over USB (all in place) and access the > information from the EDS remotely. > As I could not find a proper way for a remote interface to EDS (nor Python > bindings for that) I started to access the underlaying Berkeley database for > the contact information directly. The access is working smoothly on the local > Desktop machine, where the EDS is running. > > However, my solution to copy the file via SSH to the Freerunner; edit the > database there and copy it back does not seem to work. I read in some forums > already, that it might not be possible to access information from within a > Berkeley database when it was removed from its original environment. > I dont think copying the db file gonna help much. You can't guarantee to get it working all the time. Each backend uses a different type of storage :-( > Could anybody please give some advice, whether > - there is a way to copy the database to another machine by keeping it > working, or > - how to remotely access the EDS in Python using the proper way?? You can look at look at some sample code from deskbar applet. It was written in Python, and uses python bindings for EDS to query contacts. Not sure, if deskbar applet is still alive, but code should be hosted in git.gnome.org -Srini ___ 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
On Wed, Dec 16, 2009 at 7:05 PM, Patrick Ohly wrote: > On Wed, 2009-12-16 at 18:55 +0530, Srinivasa Ragavan wrote: >> Maildir is good, none denies it. But maildir is already there, but not >> sure how many use it. > > I do, and I know several other people who do. The question how to enable > maildir for an account is a question that comes up often on the users > mailing list, so the demand exists. If not that many people actually is > it, that's probably because switching to it requires quite a bit of > fiddling. > >> I remember multiple problems, some subdirs, >> windows support etc. Milan did an analysis, some time back, dont >> remember that very well tbh. > > Deciding to move away from mbox as the default format would be the > perfect opportunity to address these problems and make more users happy: > those who already use maildir and those who can start to use it and then > benefit from its advantages. > I really like the above statement honestly ;-). Fix up or (Re)Invent? Its the choice that needs to be made with the options and conditions at the current scenario. I would like to summarize like that. -Srini. ___ 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
On Wed, Dec 16, 2009 at 5:48 PM, Patrick Ohly wrote: > On Wed, 2009-12-16 at 16:54 +0530, Srinivasa Ragavan wrote: >> On Wed, Dec 16, 2009 at 4:46 PM, Patrick Ohly wrote: >> > On Wed, 2009-12-16 at 09:19 +0530, Chenthill wrote: >> >> On Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote: >> >> > On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote: >> >> > > * Not able to create subfolders under INBOX - >> >> > > https://bugzilla.gnome.org/show_bug.cgi?id=536240 . >> >> > I hadn't noticed the above, so I guess it's a non-issue for me >> >> > >> >> > What is the second issue? >> >> Sorry missed to mention it here, with maildir we would need to rename >> >> files for unread/read flag changes which can be avoided in the later >> >> approach. >> > >> > So you expect renaming a file to be slower than rewriting the whole file >> > content? Somehow my gut feeling says that it will be the other way >> > around. But I don't have hard data, of course. >> >> I fell it will be slower compared to the other approach. You dont >> rewrite the file entirely at all in normal usage. > > Setting mail flags was mentioned as the reason for not using maildir. > Adding a mail flag to an mbox mail requires rewriting the whole file. Or > do you assume that you can overwrite just some bytes in an existing mail > header? > > That will still lead to writing a complete sector to disk, in contrast > to renaming a file which I expect to be implemented more intelligently > by the file system. Actually, writing a micro-benchmark for this is > doable. Before you seriously consider investing effort into this, I'd > really prefer to see some hard data for a "rename vs. rewrite" > comparison. > Maildir is good, none denies it. But maildir is already there, but not sure how many use it. I remember multiple problems, some subdirs, windows support etc. Milan did an analysis, some time back, dont remember that very well tbh. >> May be when you >> expunge folder or export it, the summary data could be updated with >> the mail's mbox. But its debatable at some level, I would say. > > We are debating the merits of the actual mail storage, not the summary > data. I have wiped out folders.db often enough that I won't use > Evolution when it switches to storing valuable, unrecoverable > information like the "mail was read" flag there. Cool. Its about when you write and how you schedule it. In current mbox design, expunge, rewrites the flags back to mails from summary. Its not about keeping it permanent in the summary. > >> > 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. > > In case it wasn't obvious, I don't see the point of diverting resources > away from an established format in favor of something new. "It's mbox" > doesn't count, you would have to write the complete directory tree > handling from scratch. > > Of course, it is your time. I'm just expression my concerns as a user of > the somewhat neglected maildir format. I appreciate your feedback. Its not a decison. We want to start a discussion to see how we can improve the existing situation. I really hate 1mbox per folder design. Maildir isn't the best backend written in Evo. Given that, I preferred this data cache scheme that other backends use. Nothing otherwise! We would choose the best that comes out of this discussion. -Srini ___ 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
On Wed, Dec 16, 2009 at 5:03 PM, Ross Burton wrote: > 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. Really, we aren't inventing a new format. Its mbox, but organized a bit differently, like how some providers store, (Exchange, GW, (IMAP4 ?) store. Btw, just don't remember well, but Milan did a research of the same, moving from mbox to maildir. Milan do you remember the points to consider? It will be helpful -Srini ___ 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
On Wed, Dec 16, 2009 at 4:46 PM, Patrick Ohly wrote: > On Wed, 2009-12-16 at 09:19 +0530, Chenthill wrote: >> On Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote: >> > On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote: >> > > * Not able to create subfolders under INBOX - >> > > https://bugzilla.gnome.org/show_bug.cgi?id=536240 . >> > I hadn't noticed the above, so I guess it's a non-issue for me >> > >> > What is the second issue? >> Sorry missed to mention it here, with maildir we would need to rename >> files for unread/read flag changes which can be avoided in the later >> approach. > > So you expect renaming a file to be slower than rewriting the whole file > content? Somehow my gut feeling says that it will be the other way > around. But I don't have hard data, of course. I fell it will be slower compared to the other approach. You dont rewrite the file entirely at all in normal usage. May be when you expunge folder or export it, the summary data could be updated with the mail's mbox. But its debatable at some level, I would say. > > 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. -Srini ___ 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
On Wed, Dec 16, 2009 at 11:40 AM, Matthew Barnes wrote: > On Wed, 2009-12-16 at 01:25 +0530, Srinivasa Ragavan wrote: >> It should be rocket fast!. Expunge is just unlink one file. Change of >> flags etc rewrites just that file when upsync happens. No rewrite 2gb >> of a file, to expunge 10 mails. Startup/shutdown faster etc etc. I'm a >> fan of this, what so ever! To overcome 100K mbox files in one folder, >> distribute under multi-level subdirs and let summary know that. > > I'm liking this idea too. > > Did you have a scheme in mind for how to partition the mbox files into > subdirectories? One possibility might be to use a similar approach as > CamelDataCache. That is, take the last two (or three?) digits of the > MD5 checksum of the Message-ID and file the message into a subdirectory > of that name. That should give you a relatively even distribution and > the mbox file can be easily be located once you have its Message-ID. > IIRC Exchange uses a similar thing. Donno if that is CamelDataCache :-). Its the scheme I'm speaking off. > Also, we should be careful about using the word "standard" when talking > about mbox and Maildir. Neither of these formats are standardized, and > in fact variations abound among mailer programs. Certainly we should be > able to export messages to these formats, however we decide to store > them internally. > Should be easy, appending all the mbox files under multiple dir to one big thing should get back the old 1 mbox file format per email folder. We can have tools to do that, not in the GUI I would say. -Srini ___ 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
Hello everyone, On Wed, Dec 16, 2009 at 1:16 AM, Chenthill wrote: > Hi fellow hackers!! > I have been working for a while during last week on one the blockers > in evolution - https://bugzilla.gnome.org/show_bug.cgi?id=550414 - > 'Folder and summary mismatch error'(old one - > https://bugzilla.gnome.org/show_bug.cgi?id=213072). As a matter of fact > we have been working as a team to get the blockers down. I have not been > able to reproduce the issue or yet find the exact problematic area. > > The mismatch in the frompos index in the folder summary may be caused > by either a threading issue or a crash while storing the indexes. I am > still investigating it to find the real cause. > > Looking at other issues such as, > https://bugzilla.gnome.org/show_bug.cgi?id=522433 - 'Fails opening mbox >> 2GB', just got a thought if we could solve both the issues by, > > Approach #1, > migrating local storage from mbox to maildir format. With maildir I have > heard about two issues, > > * Not able to create subfolders under INBOX - > https://bugzilla.gnome.org/show_bug.cgi?id=536240 . > > Approach #2, > Migrate from a single mbox file per folder to mbox per email. Srini > mentioned an advantage that this would avoid the file renames that > maildir does. I think this is much like how other remote providers in > evo store the email. It should be rocket fast!. Expunge is just unlink one file. Change of flags etc rewrites just that file when upsync happens. No rewrite 2gb of a file, to expunge 10 mails. Startup/shutdown faster etc etc. I'm a fan of this, what so ever! To overcome 100K mbox files in one folder, distribute under multi-level subdirs and let summary know that. > > I thought of bring this in this list to gather more opinions to choose > the right one. The approach #2 seems a better one as we are choosing a > way for storing the messages internally in evo. Are we missing to see > anything while we choose the second one ? > > One advantage which I see with #1 is that its a standard way. You store everything as mbox only still. But one mbox file per mail, distributed in multiple subdirs. Ofcourse you dont want 100K files in one folder, which could move the bottleneck to a different place. Distribute under multi-level subfolders or something like that. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Thu, Dec 3, 2009 at 9:19 PM, Jonathon Jongsma wrote: > On Thu, 2009-12-03 at 20:35 +0530, Srinivasa Ragavan wrote: >> On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma >> wrote: >> > As some of you may know, I've been looking into moving mail down to the >> > e-d-s level. As a first step, I'm figuring out where to draw the line >> > between the front end and backend. At the moment, I'm focusing on >> > filtering. I think that the filtering functionality clearly belongs in >> > the backend (we want to filter emails as they come in regardless of >> > whether the UI is running or not). The thing I'm trying to figure out >> > right now is what that means for the filter-related classes within >> > evolution (i.e. the stuff in the filter/ directory). My first instinct >> > was that these classes belonged in the backend since that is the part >> > that should be doing the filtering. However, as I looked at it more, I >> > wasn't so sure, and I'd really appreciate insight from people who might >> > have a longer history with this code than I do. (FYI, while I was >> > getting more familiar with the filter code, I wrote up some >> > documentation that you might find helpful: >> > http://live.gnome.org/Evolution/Filters) >> > >> >> Excellent job in documenting it. Even more great, because you kept it at lgo. >> >> I'm not gonna suggest one of the below but I'm going to think aloud, >> shut me if its crap. Why should the UI be from the frontend, the >> Evolution ? If my mail runs in EDS, which reads filters from a xml >> file, may be as a small capplet/lib/bin with the backend with the UI >> to launch the filter manager. Independent of Evolution, may be Anjal >> directly can launch it. Or if we have account setup from Control >> center as a capplet, then we could launch the filter/rule manager >> independent of Evolution itself. Is that too much to ask for? >> It could simplyfy everything? Do we have a tight need of any Evolution >> components for Filters? I just don't remember, but even if there is, >> we should try to have it like this IMO >> >> -Srini > > Yes, it's a valid question. Let me quote one thing from my original > mail that wasn't emphasized very well so you may have missed it: > > "(note that when I say 'frontend', it may be the MUA > itself, or it may be a helper client library like some future > libedsmailui library):" > > So my thought was that maybe we would have a libedsmailui utility > library (similar to something like libedataserverui) that would > implement these filter editing dialogs, etc. Then evolution and anjal > could both use them by simply linking to this UI utility library. Does > that address your concerns? > Sure, it makes sense. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma wrote: > As some of you may know, I've been looking into moving mail down to the > e-d-s level. As a first step, I'm figuring out where to draw the line > between the front end and backend. At the moment, I'm focusing on > filtering. I think that the filtering functionality clearly belongs in > the backend (we want to filter emails as they come in regardless of > whether the UI is running or not). The thing I'm trying to figure out > right now is what that means for the filter-related classes within > evolution (i.e. the stuff in the filter/ directory). My first instinct > was that these classes belonged in the backend since that is the part > that should be doing the filtering. However, as I looked at it more, I > wasn't so sure, and I'd really appreciate insight from people who might > have a longer history with this code than I do. (FYI, while I was > getting more familiar with the filter code, I wrote up some > documentation that you might find helpful: > http://live.gnome.org/Evolution/Filters) > Excellent job in documenting it. Even more great, because you kept it at lgo. I'm not gonna suggest one of the below but I'm going to think aloud, shut me if its crap. Why should the UI be from the frontend, the Evolution ? If my mail runs in EDS, which reads filters from a xml file, may be as a small capplet/lib/bin with the backend with the UI to launch the filter manager. Independent of Evolution, may be Anjal directly can launch it. Or if we have account setup from Control center as a capplet, then we could launch the filter/rule manager independent of Evolution itself. Is that too much to ask for? It could simplyfy everything? Do we have a tight need of any Evolution components for Filters? I just don't remember, but even if there is, we should try to have it like this IMO -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where in the code is the autocompletion for To: field done?
On Fri, Oct 23, 2009 at 10:15 AM, Florian K wrote: > > Hello Evolution developers, > > first of all thank you for making such a great tool! > > I have built Evolution 2.26.1 from source on Ubuntu 9.04. I would like to > explore the code that handles the autocompletion of email addresses in > receipient fields. In particular I would like to see if the it's feasible to > make the number of characters to be typed before the search for matches > occurs to be configurable (I would like it to be one char, but I understand > that more are necessary if the search goes against LDAP). Look at e-d-s/libedataserverui/e-name-selector-entry.c -Srini. ___ 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
On Tue, 2009-08-04 at 10:17 -0400, Matthew Barnes wrote: > I would also like to ask the Evolution -and- Anjal developers to be very > conservative about committing to the Evolution and Evolution-Data-Server > 'master' branch after we create the 'gnome-2-28' branch. I wouldn't commit to mail/ any more for anjal (beyond branching ?), till you merge back. If I want to, I will do to master first, if I have to and backport. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Index on sqlite database
On Sat, 2009-08-01 at 13:45 -0400, Matthew Barnes wrote: > On Sat, 2009-08-01 at 11:37 -0400, Paul Smith wrote: > > Have any of the Evo hackers looked at this email from Romuald? This > > seems like a simple change that should be made. > > > > Maybe a bugzilla entry is needed? > > I commented in the bug he filed, but I also want Srini's thoughts: > http://bugzilla.gnome.org/show_bug.cgi?id=590044 Just replied on the bug. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution maintainership
Hello guys, This mail is to announce some of the role changes in the Evolution project. I have been thinking about this for a long time, and I feel that this is the best time to implement them. I am proud to announce Chenthill P (chen) as the new Evolution maintainer. He is a long time contributor to the Evolution project and has been working in the project for over 5 years. He is well known in the community for his expertise in Calendar component and has been its maintainer for the last 4 years. He has been one of the prime contributors for the Groupwise provider and Microsoft Exchange Calendar. A few of his notable contributions include libical integration with System timezone for better Daylight savings support, single-model-view design of Calendar MVC and removal of libical fork. He has mentored interns and GSOC students on Calendar search improvements, Microsoft Exchange Delegation support, Google Calendar integration etc. I am also proud to announce that Matthew Barnes (mbarnes) is joining Chenthill and support him as the Evolution co-maintainer. He has been contributing towards Evolution for over 3 years and is the Mail maintainer for the last 2 years. He has made significant contributions towards obsoleting several libraries, and helping to migrate to newer technologies. He has been working on Kill-Bonobo which is a major revamp of Evolution Shell. This involves rewriting Evolution components and UI which is a focus area for Evolution 3.0. Going forward, I will be focusing on improving evolution infrastructure for netbooks and other devices; chen and mbarnes would be driving the Evolution project direction and releases. Please join me in congratulating chen and mbarnes, and in wishing them good luck in their new roles. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GNOME 3.0 - Evolution plans & IRC team meeting
Guys, We have made some proposals to the release-team on GNOME 3.0 plans for Evolution. Specially release/scheduling specifics. Read through the thread. http://mail.gnome.org/archives/release-team/2009-June/msg00018.html We'll probably workout the exact schedule/decision. I wanted to discuss this in tomorrow irc team meeting. But due to my busy schedule and tight meetings tomorrow, I won't be able to make it, and I want to post-pone the team meeting to thursday (UTC 10:00) just this time. Sorry, if this is a late notice. Try to make it or keep me informed if you have some suggestions/thoughts. TIA. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] How to get information that there is some unsent mails pending with evolution??
On Fri, 2009-04-03 at 10:57 +0530, sandeep gupta wrote: > Hi all, > > I want to write a script that will check any unsent mail in Outbox > before shutting down system, if yes than it will popup a message of > unsent mail and ask user to continue shutdown. > sqlite3 ~/.evolution/mail/local/folders.db "select count(*) from outbox where deleted != 1" This could return you the exact number of mails waiting on the outbox. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Own project / idea for Google summer of code 2009
On Fri, 2009-03-27 at 12:32 +0100, Pavol Srna wrote: > Hello, > > I would like to discuss my own project / idea for Google summer of > code 2009 and if you are interested in, then I would like to find a > potential mentor for this project. > I am a daily user of GNOME desktop environment and I am missing > useful, user-friendly synchronization support with the possibility of > broader settings between Evolution (Calendar, phonebook etc.) and > mobile devices (Nokia hand phones and so on) via bluetooth. I will > introduce a plug-in for Evolution which can easily prepare the mobile > device for synchronization, and which let the user set up a variety of > synchronization settings and in really user-friendly way synchronizes > all the required data in both directions. > There have been multiple solutions for this already. OpenSync, SyncEvolution, GNOMEPilot, Conduits, [etc]. Part of these arent fully there. Your project looks to me like an another new project in that direction. New project is good, but its better to look at existing frameworks and see how you can fill the gaps to make it the best. I would suggest to read about these, ping those individual maintainers on the details and propose a solution, that would be widely accepted. HTH -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] IMAP4 Camel Provider.
On Tue, 2009-03-24 at 17:54 -0400, Pat Suwalski wrote: > Hello, > > I was wondering if anyone knew of any plans or quick fixes to get e-d-s' > IMAP4 provider building again (--enable-imap4=yes). With the 2.24.5 > release it breaks with the following: IMAP4 wasn't a supported provider since 2.8.x [or 2.10.x - don't remember that]. It was with drawn from the tar > > camel-imap4-utils.c: In function ‘uidset_add’: > camel-imap4-utils.c:309: error: ‘CamelFolderSummary’ has no member named > ‘messages’ > > The same is true in current trunk. > > Investigating the changes that cause this reveals a whole snowball of > "madagascar" changes. > The disk summary changes did it. IMAP4 isn't ported for this. > The plan was to bring the evolution-scalix plug-in, which is based on > the imap4 code, up to date. However, looking at the changes made to the > plain old imap code (revision 9125), I'm in over my head. I just don't > have a grasp on what all of these functions do, let alone the changes to > them. > You can contact me 'srag' on #evolution. It should be very simple to port a provider to Disk summary specific Camel -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EPlugin events
Nick, IIRC, there was a plugin for the same. Don't remember the name. But it wasn't approved to be in upstream. -Srini. On Thu, 2009-03-26 at 08:14 +1100, Nick Cronin wrote: > Hi, > I was thinking I'd have a go at writing a very small plugin for > evolution and I thought a good place to start was a simple minimise to > tray plugin. I downloaded the plugin manual and the source code. > From what I can gather there is no event that I can hook onto that > states if the program is going to be or is currently minimized. Is > there a way I can hook directly onto the gtk events via EPlugin or > would I need to insert my own EPlugin event (which would wrap the gtk > event) to do this? > Thanks, > > Nick Cronin > ___ > 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] [Evolution] Evolution 2.26 released
On Wed, 2009-03-18 at 16:42 +0800, Daniel.Li wrote: > Excellent work!!! > > > But I have a simple question here.As u know, I have lots of e-mails. And > it takes a lot of time compiling the souce code, maybe there will be > some configuration issues. > > So, is there any simple way to upgrade 2.24.3 (ubuntu 8.10) to 2.26.0? > Maybe there is a repository that can be added to apt source-list and > simply use "sudo apt-get update". Sorry, you probably need to ask ubuntu packagers/mailing list. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.26 released
Hello Everyone, The Evolution Team is pleased to announce the release of * Evolution 2.26.0 * Evolution-Data-Server 2.26.0 * GtkHTML 3.26.0 * Evolution Exchange 2.26.0 * Evolution MAPI 0.26.0 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.26/gtkhtml-3.26.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/2.26/evolution-data-server-2.26.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.26/evolution-2.26.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.26/evolution-exchange-2.26.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-mapi/0.26/evolution-mapi-0.26.0.tar.bz2 Thanks to all who contributed to the Evolution 2.26 release. What is new in 2.26 === Exchange MAPI - connector to connect to Exchange 2007 servers PST import plugin. Support CalDAV for VTODO and VJOURNAL Mail summary database made index-able for Tracker/Beagle Dropped libical fork & merge with upstream libical Calendar performance fixes in view. and nearly 400 bug fixes and 30 crasher fixes. == Reporting Bugs == If you have problems with 2.26.0, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. Kindly check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Interface Spec for PIM component interoperability
Sorry for a late reply - busy on lots of things around. Sure, looks like great idea. Count me in. -Srini. On Mon, 2009-02-16 at 13:35 +0100, Till Adam wrote: > Srini, Berndt, > > > > I know this thread is very old (hopefully Evo sorts by newest mail in > thread, not olders, like KMail did, until recently ;), but I thought > I'd hijack it anyhow, for a proposal: > > > > What do you guys think of a PIM BOF at the Gran Canaria desktop summit > this year? I'd try to get any interested Mozillistas and Maemo-ites > involved as well, if you agree that this is a good idea. Hopefully > there'll be some around. Would give us all a chance to discuss the > state of things and how we can best interoperate and cooperate, in the > future. > > > > Game? > > > > Till > > > > On Thursday 21 August 2008 11:24:57 Srinivasa Ragavan wrote: > > On Wed, 2008-08-20 at 14:14 +0200, Holger Berndt wrote: > > > Hello Evolution hackers, > > > > > > I just subscribed to the list, and browsing the archives this > message > > > may or may not have an overlap with the recent thread about EDS > D-Bus > > > interface in "Future of eds bindings". > > > > > > I am a supporter of the desktop independant, GTK+ based MUA Claws > Mail. > > > Its (few) developers are pretty evenly split between between being > KDE, > > > GNOME, and XFCE users. > > > > > > I've thought many times that it would be great to have a > > > (maybe freedesktop.org) standard for PIM component access and > > > interaction. Ideally, this would allow for all PIM components > > > implementing this spec to be interchangable without loosing > > > integration, so the user could choose calendar, addressbook, > mailer etc > > > independantly, and still have a nicely integrated PIM suite. This > could > > > be achieved by defining a "common language" for popular PIM tasks > > > involving multiple components (by "PIM component", I mean MUA, > > > calendar, addressbook, notes application etc). > > > > Sure, a valid requirement. Evolution gets used by quite a few KDE > users, > > I have received feedbacks from such users on the similar lines. > > > > > Let me give a few examples of such tasks: > > > What a MUA could request: > > > - dear addressbook, whoever you might be, please add the following > > > contact: John Doe > > > - dear addressbook, please give me a list of all contacts > > > - dear addressbook, please open up contact xy for editing. Or just > show > > > me your main window. > > > - dear calendar, whoever you might be, I just received a meeting > > > invitation via email. Please insert that event into my calendar > > > > > > Basically, it would be necessary to define a set of interfaces > > > (possibly D-Bus services) along the lines of > > > org.freedesktop.pim.addressbook.storage > > > org.freedesktop.pim.addressbook.ui > > > org.freedesktop.pim.calendar.storage > > > org.freedesktop.pim.calendar.ui > > > org.freedesktop.pim.mua.storage > > > org.freedesktop.pim.mua.ui > > > etc, where in the case of GNOME Evolution could provide the *.ui > > > interfaces and EDS could provide the *.storage interfaces. > > > > Infact, I'm open to have some defined common interfaces that > multiple > > apps (Mail, Calendar) can interface with the PIM daemons (EDS, > Akonadi, > > etc). Infact, starting next week (planning bits atm), I'm gonna work > on > > moving mail to e-d-s to make EDS complete. Then defining common > > standards/interfaces (across Mail, Contacts Calendars) would help > apps > > to operate transparently, independent of the desktops. > > > > -Srini. > > > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > > > > -- > Till Adam > KDAB - platform independent software services > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error Reporting in libebook
On Fri, 2009-01-16 at 12:22 +, Ross Burton wrote: > 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, didn't we break once before by stripping off some exposed bonobo stuff on the APIs ? So, is this new on the branch? -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.24.3 and beyond
Hello guys, Today I released Evolution (and friends) 2.24.3. This is the last stable release in the GNOME stable cycle. But given the issues that 2.24.x series introduced, we would be releasing Evolution 2.24.4 and 2.24.5 and there will be full support till the release of Evolution 2.26.0 [March 16]. I haven't worked out the dates exactly, but plan to have one release later in January and another in mid/late February. This would one of the agenda in this week's team meeting. Thanks a lot for all your support. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all
The Exchange patch looks fine to me. -Srini. On Mon, 2009-01-05 at 12:28 +0100, Philip Van Hoof wrote: > On Mon, 2009-01-05 at 00:42 +0530, Srinivasa Ragavan wrote: > > > > On Fri, 2009-01-02 at 13:25 +0100, Philip Van Hoof wrote: > > > Hi there evos, > > > > > > For an EPlugin that I'm working on I will need a Camel API to get the > > > filename of the cache. > > > > Sure and the patch seems fine to me, but the Exchange portion of the > > patch is missing. It should be similar/simple. > > Attached. > > Let me know when it's all reviewed and/if I can commit it. > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all
Hey Philip, [Im lagging in my mail-replies, still a lot to go, due to my 3 week vacation.] On Fri, 2009-01-02 at 13:25 +0100, Philip Van Hoof wrote: > Hi there evos, > > For an EPlugin that I'm working on I will need a Camel API to get the > filename of the cache. Sure and the patch seems fine to me, but the Exchange portion of the patch is missing. It should be similar/simple. > > I will attach a patch that adds this API. The EPlugin that I'm developing is > available at Bug# 565091 and more information about it can be found at > > http://live.gnome.org/Evolution/Metadata. > > > I added a bug for tracking this request: > > http://bugzilla.gnome.org/show_bug.cgi?id=566279 > > I know that for maildir (cur, tmp, new) and mbox (seek position) it's a > little bit controversial to return a filename. For maildir I always use > the cur-file one and for mbox I added "/!seek_pos" to the end of the > returned filename. > > The reason why I need this is that for indexing already cached E-mails, > Tracker will MIME parse what we can MIME parse. For example filenames > and Exif data of attached images is stolen out of the cached items, to > be made searchable. > > We don't want to require Evolution to eat all the code involved in > indexing massive amounts of file formats. Best thing we can do right now > is to simply pass the filenames over IPC. > > We STRONGLY recommend to the Evolution team to: > > a) migrate away the IMAP specific data cache (see c to store separate parts) I thought we already store parts separate. Is is just about the encoding or more than that? I seriously don't have an idea on this. May be Fejj, Sankar, Matt can add on it. > b) migrate away the mbox data cache (the all-in-one file crap) I'm all for it. Once I thought of doing this, but the options were like Maildir or a format of one mbox file per mail in a distributed folder [CamelDataCache sort of format, like imap4/GW/Exchange]. But IIRC Fejj, had some concern like, Local still might be good to be held in a 'standards' way. I know it hurts us on expunge/mailbox rewrite etc. > > And to > > c) invent a better storage format that doesn't store the attachments in > server's (usually) Base64 encoding. The one format to rule them all. > > Instead store the encoded attachments in decoded format (original file > format). This will reduce diskspace (encoding increases diskspace usage) > and will make it more easy to scan the original file for XMP and Exif > information. Don't try to gzip or whatever anything. None of that makes > any sense (original files are usually compressed ideally already). > > For example: devices that want to compress have filesystems that do this > for you. Don't be silly trying to do this yourself. > > By storing the encoded version the only thing you currently gain is that > the feature "view E-mail source" doesn't need to recode the attachments. > > This ain't a much-used feature. It doesn't have to be fast, at all. > > No it doesn't. Really it doesn't. Is thatz it? I need some other opinions, I don't have much thoughts here. Sankar, Matt, Fejj? > > For Maildir I recommend wasting diskspace by storing both the original > Maildir format and in parallel store the attachments separately. > > Maildir ain't accessible by current Evolution's UI, by the way. > > For MBox I recommend TO STOP USING THIS BROKEN FORMAT. It's insane with > today's mailboxes that easily grow to 3 gigabytes in size per user. I second your thoughts for MBox stuff. > > > Once all start using the CamelDataCache API, implementing that new > format and implementing converters wont be very hard. > > For existing CamelDataCache users it's just one format to convert. For > IMAP, mbox, Maildir and mh it's indeed a few extra formats to handle > using a conversion. Wont kill you to implement that, and, I'll help. Thatz so nice of you to help us :-) -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] State of the Bonobo removal effort for Evolution
On Mon, 2008-11-17 at 01:36 -0500, Matthew Barnes wrote: > Hi folks, > > One of the goals for Evolution 2.26 is to finally remove the use of > Bonobo and BonoboUI from Evolution [1] in favor of equivalent > functionality now provided by the GTK+ stack. This is happening in > parallel with Ross Burton's effort to port Evolution-Data-Server from > using Bonobo to D-Bus as the communication medium. The two efforts are, > at this point, still progressing independently. > > I've been working on removing Bonobo from Evolution since late August > and have been publishing my source code changes to a Subversion branch > named "kill-bonobo" [2]. I've also been maintaining a wiki page by the > same name [3] with screen shots and somewhat regular updates, though the > updates tend not to go into much technical detail. > > With the U.S. on daylight savings time now, our weekly IRC meetings are > at 05:00 EST and, not being much of a morning person, I've been waking > up in time even less frequently than I did when they were at 06:00 EST. > So I feel like I've been a little incommunicado lately about how things > are progressing. > > I hope to correct that with this, the first of a series of postings > about where things stand and also some technical details about the > direction I've taken with the newly-rewritten EShell. > > The wiki page [3] already has a brief overview of the new shell design, > along with a link to some incomplete and slightly out-of-date API docs > for it [4]. I'll try to improve the completeness and quality of the > documentation over the next week. > > > So, for the remainder of this first post I'll cover schedule. > > Is this going to make it in time for 2.26? > > Short answer is: I still don't know. > > Red Hat was gracious enough to allocate two months for me to work on > this full time. In that time I managed to complete the new EShell, more > or less finish the Contacts, Tasks and Memos modules, and get a good > start on the Calendars and Mail modules. But with November already here > I'm obligated to focus on other issues of interest to Red Hat during > business hours, which leaves evenings and weekends (when I can find > time) to work on this. Suffice it to say, progress has slowed. > > Unfortunately, no matter how much I test the "kill-bonobo" branch > beforehand, the truth is when we finally do merge it to trunk there > _will_ be regressions. Lots of 'em. Hopefully no major show-stoppers > but lots of little things I missed. The scope of the changes here is > simply too massive for me to catch everything. Heck, I'm still fixing > little bugs I missed in the composer rewrite from earlier this year and > that was of much smaller scope than this. We'll need a few months of > heavy testing and bug reporting from developers and interested members > of the community after the merge and before the stable release date. > > So, I've drawn a line in the sand: 2.25.3. If the merge doesn't happen > in time for that release, which is scheduled for mid-December, I'm > inclined to re-target the feature to 2.27.1. > > As I said, at this point I don't know if I'm going to make it in time. > There's still a lot of work left. Finish the Mailer and Calendar for > starters, and then go through and rework most of the plugins (EMenu and > EPopup are going bye-bye). Plus I have a TODO list a mile long of loose > ends I have to go back and address. Evolution-Exchange will likely need > some rework, though to what degree I'm not yet sure. And I also don't > know what impact all this will have on the MAPI work. > > It's getting there. Just not as fast as I would've liked. In the next > posting I'll talk about the new shell design and touch on some of the > things it now handles for you that the current shell does not. > > If you have questions, suggestions or concerns, please don't hesitate to > shoot me or the list an email. After all, I'm writing this in hopes of > getting some feedback. > Thanks for the great update on this Matt. Its going to be a tough time for many of us for the next couple of months. That's one reason, I asked you to look at Camel/Gobject stuff for 2.27.x. May be, we have too many things to do, which would take more than a 6-month cycle? May be a bigger GNOME 3.0 schedule might fit us well to revamp most of Evolution [Split it, Kill bonobo, Write Accounts well etc]. Anyways, just some thoughts. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GObject-based Camel
Hey Matt, On Sun, 2008-11-09 at 12:52 -0500, Matthew Barnes wrote: > Over the weekend I hit a milestone with a science experiment I started > earlier in the year to turn Camel into a GObject-based library with > minimal API breakage. The short-term goal of this effort is to make it > easier to generate language and D-Bus bindings for Camel. > This is awesome news :-). > I now have running code which I've posted to a new evolution-data-server > branch called "camel-gobject" [1]. The branch contains a couple very > small patches (evolution.patch and evolution-exchange.patch) that must > be applied before building Evolution against the GObject-based Camel > library. > > Evolution seems to be working just fine with my standard setup, but I > haven't tested all the built-in Camel providers and various third-party > extensions. If others want to chip in with the testing I'd be grateful. > > > Techie Details > -- > > My approach was basically to pull off the same stunt that was done to > GtkObject when GObject was introduced: turn the base CamelObject class > into a GObject subclass, and convert the CamelObject API into a set of > thin wrappers for equivalent operations in GObject. For example: > > camel_object_ref() now calls g_object_ref() > > camel_object_unref()now calls g_object_unref() > > camel_type_register() now calls g_type_register_static() > > ...etc... > > Obviously this breaks Camel's ABI. There's no way around that. I think, you are correct. This needs to happen at some time. > > The (intentional) API breakage is very minimal: > > CamelType is now an alias for GType. It is no longer a pointer > to the class structure. That was supposed to be an implementation > detail anyway, but Camel (and Evo, and Evo-Exchange) exploits that > in a number of places. The class structure can be properly accessed > using camel_type_get_global_classfuncs(), which is now an alias for > g_type_class_peek(). > > The corollary to that is when to fetch the parent class structure. > Most classes define a static "parent_class" pointer for chaining up > in class methods. The "parent_class" pointer should be set in the > class initialization function, NOT before the type registration in > get_type(). Just like you would in normal GObject code. There > were LOTS of places in Camel were that needed fixing. > > Camel interfaces are dead, but they were never really used anyway. > > The other half of the problem was CamelObjectBag. It formerly shared a > mutex with CamelObject's reference counting, I think because CamelObject > ref's and unref's were non-atomic. GObject's reference counting is > atomic, so with that issue out of the way I gave each CamelObjectBag its > own mutex, cleaned up the code a bit, and split it off into a separate > source file (camel-object-bag.c). After an evening's worth of debugging > it seems to be working fine now. > > > Now What? > - > > So with the "interesting" part now done, next comes the long and tedious > part: rewriting all the internal CamelObject boilerplate into GObject > boilerplate and making sure we're not using any newly deprecated API. > But that can be done gradually and with help from others. > > In time I'd also like to explore taking greater advantage of GObject > signals and properties in Camel, and also deprecating CamelArgV and > CamelArgGetV. Also the Camel Events to GObject signals right, or you meant the same? > > I haven't discussed this with the other Evolution/Camel developers yet, > so there are currently no plans to include it in 2.26. That may change, > but for now it remains purely experimental. 2.26 might be a very tough one, with Kill-Bonobo also in, we may have too many things to shape up. > > Matthew Barnes > > > [1] > http://svn.gnome.org/viewvc/evolution-data-server/branches/camel-gobject/ > > > ___ > 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] Does evolution source still contains GPLv2 code?
Jeff, The COPYING (GPLv2) old license, COPYING.LGPLv2 COPYING.LGPLv3 are present in the tarballs. Evolution still has some files left & not moved to LGPLv2/LGPLv3. NEWs files might have been saying that some license changes code went in. Sorry for the confusion. -Srini. On Fri, 2008-10-17 at 11:01 +0800, Jeff Cai wrote: > Hi > > From the 2.24 tar package and svn trunk, I can still find the COPYING > file which says that it is "GNU GENERAL PUBLIC LICENSE v2". But from > NEWS, it says "Evolution source code license changed to LGPLv2 & LGPLV3 > (Sankar P)". > > Sankar, I'm curious about whether evolution still contains GPLv2 code. > > Jeff > > ___ > 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] Too many open files for folders.db
Jeff, This should be fixed in stable as of last wednesday or so. -Srini. On Mon, 2008-10-13 at 11:45 +0800, Jeff Cai wrote: > > Whenever you click a folder, the folders.db will be opened once. So if > you run Evolution for > a while, you will find dozens of file handles of folders.db. Is this a > bug? or is it expected > behavior? In Solairs, the default open file limit is 256, while in > Linux is 1024, so the error > is easily produced in Solaris. > > Can Evolution share the same file handle to folders.db? or can the > handle be closed if you > switch to a new folder? > > Thanks > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
Rob, IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still OpenSUSE ships with in-built libdb. I'm not aware of any other distro. JPR, who use to maintain Evolution few years back, gave me the notes on why it was decided to go this way (forking libdb). So if we have answers for all those points, I'm fine for that. We don't want to break anything thatz fine otherwise. I'm not tracking libdb at all, if you have the answers, then lets recalculate and plan for it in 2.26. -Srini. On Mon, 2008-10-06 at 14:59 +0100, Rob Bradford wrote: > Since we're at the start of the cycle shall we go ahead and drop the > included libdb ? and thus add a formal requirement on using the system > version. AFAIK all the distributors ship with using the system > version... > > I've updated the bug #410164 with a patch that makes this change. > > Regards, > > Rob > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers --- Begin Message --- 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: - Berkeley's libdb - 3.1.17 db3 is available from http://www.sleepycat.com. Make sure to get 3.1.17, it isn't the latest version. --- IMPORTANT WARNING --- The on-disk format of DB files has been changing between versions 2, 3 and 4. Also, because of the libdb API, there is no way to easily handle the different formats from within the application. For this reason, Evolution has chosen to use one specific version of the library (version 3) and stick to it, so that users do not need to convert their addressbook files to use them with different version of Evolution. That's why Evolution REQUIRES libdb 3.1.17, and NO OTHER VERSION. If you force the check to accept a version different from 3.1.17, your binary of Evolution will be using a different format from the chosen one; this means that it will not be able to read addressbook databases created by other versions of Evolution which were compiled in the standard way. Also, we DO NOT GUARRANTEE that Evolution will work with different versions of libdb at all, even if it can be trivially made to compile against them. SPECIAL NOTE FOR BINARY PACKAGERS: If you are making binary packages for end-users (e.g. if you are a distribution vendor), please statically link Evolution to Berkeley DB 3.1.17, as mandated by the configure.in check. DO NOT patch configure.in to work around the check. Forcing the check to link to a different version of the library will only give headaches and pain to your users, who will see their addressbook disappear and will complain to us (the Evolution team) about losing their data. Besides, libdb will be linked statically, which means that your distribution doesn't actually need to ship DB 3.1.17 itself separately. The Evolution team will be infinitely grateful for your co-operation. Thanks. This proved quite painful for distros (hanging on to a specific version) though so we moved it inside e-d-s eventually. That way we always had a known quantity. === Ross, if we have an answer for this, we can close on this immediately. -Srini. On Fri, 2008-04-25 at 08:46 +0530, Srinivasa Ragavan wrote: > Ross, > > IIRC, it was done because, every libdb update broke Evolution or libdb > wasn't so stable release over release. Also OpenSUSE uses statically > linked libdb. But most of the hackers I know, dynamically link libdb. > I'm favor of the change. But lemme ping some old evolution hackers who > were part of this change, to understand what they feel about it. > > -Srini > On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote: > > Hi, > > > > I think that we should remove the fork of Berkeley DB from the Evolution > > Data Server source. Debian, Ubuntu, Gentoo and Fedora all use > > --with-libdb to dynamically link to a system library, so it is known to > > work. > > > > This would involve removing libdb from svn, and always dynamically > > linking to libdb instead. --with-libdb would still exist for people who > > want to use a custom libdb, but it would default to /usr. > > > > Thoughts? > > > > Ross > > ___ > > 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 --- End Message --- ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS ABI changes in 2.24?!
On Sat, 2008-10-04 at 10:57 +0200, Patrick Ohly wrote: > Can such ABI changes please be discussed on this list? I'm interested to > hear about them beforehand and won't notice them if they are only > discussed on IRC or in a bug tracker entry; there may be others in the > same position. Thanks! > Sure. I would make sure that such things come up on the list here-on. Infact I'm doing it for Camel for 2.24. > In 2006 Michael Meeks wrote on this list that "I -thought- we had some > agreement written in blood that the e-d-s ABI was now frozen." and in > the camel Bugzilla entry #543389 Srinivasa again confirmed that "we > support libebook/libecal as supported APIs". Does that include > libedataserver? > > That library is necessary when handling more than just the default data > sources because it provides the e_source_* calls. Therefore I consider > it part of the libebook/libecal API - agreed? > > I think I agree to that. Just that it wasn't explicit. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-patches] FreeBSD7 timezone symbol incompatibility - widgets/e-timezone-dialog/e-timezone-dialog.c
In future, create a bug in Bugzilla and post your patch against the bug. It helps us to track every incoming patch, in case something gets missed out on emails. Also, where do you have 'char * timezone(int zone, int dst);' declared? -Srini. On Wed, 2008-09-24 at 18:54 +0400, Roman Rybalko wrote: > Hi All, > > uname -a > FreeBSD roma.home 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 > 19:59:52 UTC 2008 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 > > I can't compile the subj because I have another "timezone" symbol: > char * timezone(int zone, int dst); > > but in widgets/e-timezone-dialog/e-timezone-dialog.c is such code: > #ifndef G_OS_WIN32 /* Declared properly in time.h already */ > extern char *tzname[2]; > extern long timezone; > extern int daylight; > #endif > > I see this is defined correctly on Linux but it is not on FreeBSD. > > I've attached my patch. > Though there is probably need something to do with win32, because I > don't know whether there is localtime_r and gmtime_r > > ___ > Evolution-patches mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/evolution-patches ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.24 released
Hello Everyone, The Evolution Team is pleased to announce the release of * Evolution 2.24.0 * Evolution-Data-Server 2.24.0 * GtkHTML 3.24.0 * Evolution Exchange 2.24.0 * Evolution-sharp 0.18.0 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.24/gtkhtml-3.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/2.24/evolution-data-server-2.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.24/evolution-2.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.24/evolution-exchange-2.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-sharp/0.18/evolution-sharp-0.18.0.tar.bz2 What is in 2.24? Message Templates WebDAV Contacts support Google Contacts support Custom header support while sending mails Single Model view for Calendar Sqlite Based message summary (aka Camel On-disk Summary) New Bonobo-less composer for Evolution Quota support to IMAP/POP accounts Gtk+ Recent manager integration in Composer Contact-list for Exchange and 530 bugs and approximately 50 crashers fixed. Thanks to all who contributed to the Evolution 2.24 release. Known Issues The new sqlite based message summary might have some performance/mismatch count issues in 2.24.0. We are working hard to fix all of them in 2.24.1. Please report such issues to bugzilla and add as a dependency to http://bugzilla.gnome.org/show_bug.cgi?id=543389 meta-bug. == Reporting Bugs == If you have problems with 2.24.0, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. Kindly check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI Exchange Connector will replace current Exchange connector?
On Wed, 2008-09-24 at 16:26 +0800, Jeff Cai wrote: > Hi, > > I have two questions on MAPI Exchange connector. > > 1. When will MAPI connector officially become one part of > Evolution? > By 2.26 it should become official. We are working out the licensing part. > 2. If MAPI connector is in, will the current Exchange OWA > connector be > removed? or they will both exist? I doubt, if OWA will be removed. But atleast won't be the default, given that MAPI connector will work from Exchange 5.5 onwards till Exchange 2007. My strong feeling is that we would still support/ship OWA connector, but may not attract much new features or great attention etc. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory
On Wed, 2008-09-24 at 01:38 -0500, Hans Petter Jansson wrote: > On Mon, 2008-09-22 at 13:31 +0530, Srinivasa Ragavan wrote: > > > > Wouldn't it be possible to use a different directory, e.g. > > > "mail/local-index/folders.db"? That would avoid both problems. > > > You end up seeing a new folder local-index in 2.22/older and a > > folders.db folder under it. :( > > Wouldn't that just happen if you had > "mail/local/local-index/folders.db"? I was hoping you could place > local-index or something equivalent outside the mail/local/ hierarchy > entirely - either directly under "~/.evolution/mail/" or, as Ross > suggested, in "~/.cache/evolution/" (I like the latter a lot). I'm just trying out a new model, like a single-db for entire evolution-accounts-folders, instead of db-per-accounts/table-per-folder, which forces this. In the new model, ~/.evolution/mail/summary.db could be for entire Evolution. Vfolders would be even more faster, being single table. Anyways, just exploring. Would share when I have things in better shape. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory
HPJ, > > HPJ, the summary can't be named like this, since, its possible that > > something like this already exists. .ibex.index has a traditional > > meaning and would be more of abusing it in the newer versions. > > Wouldn't it be possible to use a different directory, e.g. > "mail/local-index/folders.db"? That would avoid both problems. You end up seeing a new folder local-index in 2.22/older and a folders.db folder under it. :( FWIW, I did give it a try, during the initial phases, but I abandoned it, since I was short of time. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory
Hello Guys,
On Fri, 2008-09-19 at 22:14 -0500, Hans Petter Jansson wrote:
> [ Adding evolution-hackers to Cc since this contains potentially useful
> feedback and some questions ]
>
> On Fri, 2008-09-19 at 18:06 +0100, Michael Meeks wrote:
> > On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
>
> > > Note 2: If you ran the newer version of Evolution previously, you should
> > > delete the sqlite database it creates before reverting to the old one -
> > > otherwise it will think the sqlite database is an mbox and try to index
> > > it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.
>
> > That - is really bad. Can we not name our db in some way that this
> > doesn't happen ? is there really no solution here ? if not, why are
> > these databases in a place where older versions get confused & start
> > doing stupid things ? - can we not put them somewhere else ?
>
Michael, Its n't possible to keep it there still not findable by the old
version. AFAICS, { ".msf", ".ev-summary", ".ev-summary-meta",
".ibex.index", ".ibex.index.data", ".cmeta", ".lock" } are the possible
extensions that the old version of Evolution ignores. But these have
definite meanings and possible they exist as locks, metafiles or
old-type-summaries. Naming the new summary that way would probably erase
the real data.
> That's a question for the Evo team, I guess - it looks like it could be
> trivially fixed by moving the folder.db somewhere else, or calling it
> folder.index or folder.ibex.index or whatever Evolution traditionally
> filters out.
>
HPJ, the summary can't be named like this, since, its possible that
something like this already exists. .ibex.index has a traditional
meaning and would be more of abusing it in the newer versions.
> To Evolution's credit, my 500MB folder.db binary blob didn't cause it to
> crash - it showed up as a bogus local mail folder after about 15 minutes
> of disk churn - but it did throw errors whenever it needed to pull data
> for vfolders.
>
But, the old version shouldn't touch the folders.db automatically,
meaning the new summary would be safe, unless the user manually deletes
or adds mails to it.
> Also, it looks like old summary/index files aren't removed - does it
> require both the sqlite database and summaries now? It increases disk
> space consumption quite a bit.
That is left purposefully. Incase you are a user switching across
versions, probably you would have to recreate summaries every time you
do. But first time, we just migrate and don't care later on. So if you
aren't a user of that category, a rm of it manually should suffice.
[probably some more summaries left on the other accounts]
>
> > Switching between versions, should work right ?
>
Michael, AFAICS, it should work fine, we don't touch old summaries
written by old version. If it happens, file a bug (I dont think it
happens ):-) Just that the old version reports you of a new folder
folders.db.
Should we ship a patch for older Evolution versions to ignore
folders.db? May be worth for power users of SLEs and RHEs, who might
still use older version & new version.
-Srini
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
On Wed, 2008-09-03 at 09:18 +0200, Frederic Crozat wrote: > Le mardi 02 septembre 2008 à 14:43 +0530, Srinivasa Ragavan a écrit : > > On Tue, 2008-09-02 at 09:23 +0200, Frederic Crozat wrote: > > > Le lundi 01 septembre 2008 à 19:55 +0200, Patrick Ohly a écrit : > > > > On Thu, 2008-08-21 at 12:37 +0530, Chenthill wrote: > > > > > Thanks, I will send out a mail to the list mentioning the > > > > > critical > > > > > fixes which have gone in recently in the stable branch which needs to > > > > > be > > > > > taken into the distro's. > > > > > > > > Bug #548268 is in trunk (thanks Chenthill!) and tested automatically > > > > now. The test showed that the time zones in South America and Australia > > > > were also affected. > > > > > > > > I think we should send out that bug list to the distributors ASAP. > > > > Debian Etch is already frozen. Chenthill, do you have the list ready and > > > > can you send it both to this list and the distributor list? > > > > > > > > My own proposal for inclusion are > > > > * 548268: time zone conversion incorrect > > > > * 546934: [Exchange Connector] contact change tracking is broken > > > > (required by SyncEvolution) > > > > * 499932: [Bug 499932] Not deleting from e-mail server after > > > > specified time > > > > > > Frankly, I think it would be much better to do a 2.22.x release for the > > > needed fix : you'll get updated translations as a bonus and > > > distributions might be more willing to push it, rather than try to apply > > > a list of patches. > > > > I think this should be discussed at d-d-l/release-team than lowering it > > to Evolution/any-other-project. We currently follow GNOME cycle, as you > > know. Unless we hit to a serious issue, you will be always be the > > waiting for a release, where as developers would waiting for a more > > better time to do it. > > I was just talking for this particular list of bugs, not in general. Ah ok. > > Eog or gthumb have been doing additional releases after the .3 release > for quite some time. > > You could also delegate the release process to other people who would be > willing to take care of it. Its just not about the the 3 hour release/tarball/sanity. But the amount of extra effort we put to review patches for stable, etc. Anyways, I think if more and more people ask for it, lets see if we can work out a schedule post .3. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
On Tue, 2008-09-02 at 09:23 +0200, Frederic Crozat wrote: > Le lundi 01 septembre 2008 à 19:55 +0200, Patrick Ohly a écrit : > > On Thu, 2008-08-21 at 12:37 +0530, Chenthill wrote: > > > Thanks, I will send out a mail to the list mentioning the critical > > > fixes which have gone in recently in the stable branch which needs to be > > > taken into the distro's. > > > > Bug #548268 is in trunk (thanks Chenthill!) and tested automatically > > now. The test showed that the time zones in South America and Australia > > were also affected. > > > > I think we should send out that bug list to the distributors ASAP. > > Debian Etch is already frozen. Chenthill, do you have the list ready and > > can you send it both to this list and the distributor list? > > > > My own proposal for inclusion are > > * 548268: time zone conversion incorrect > > * 546934: [Exchange Connector] contact change tracking is broken > > (required by SyncEvolution) > > * 499932: [Bug 499932] Not deleting from e-mail server after > > specified time > > Frankly, I think it would be much better to do a 2.22.x release for the > needed fix : you'll get updated translations as a bonus and > distributions might be more willing to push it, rather than try to apply > a list of patches. I think this should be discussed at d-d-l/release-team than lowering it to Evolution/any-other-project. We currently follow GNOME cycle, as you know. Unless we hit to a serious issue, you will be always be the waiting for a release, where as developers would waiting for a more better time to do it. We sort of do stable releases for upto 4 months (after the .0 release) or so, where as the newest version arrives in approx two months after that. What we currently discussing are those 2 months, where the stable branchs doesn't have a release, unless there is a security/vulnerability issue. It has both pros and cons. But, I would say, notify bugs, so that distro's can pick at their choice. Giving a window of a release, can probably break at times. Just my thought. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI backend
On Tue, 2008-09-02 at 19:47 +0200, Patrick Ohly wrote: > On Tue, 2008-08-19 at 20:22 +0200, Patrick Ohly wrote: > > I don't have root access, therefore I compiled all the required > > components (Samba, libmapi, EDS, Evolution) from source. I haven't tried > > to run it yet. > > I'm on Exchange 2007 now. Setting up the MAPI backend worked, but I had > to patch the source to get past a calendar authentication problem [1]. > Afterwards I could see some events, but not all. It seems that recurring > meetings are not yet supported: these seem to be the ones that I'm > missing and creating one anew leads to an unspecific error message. > > I need the MAPI backend primarily for calendars. As it is now I cannot > use it (most of my meetings are recurring), so I'll have to depend on > OWA for the time being. > > FWIW, I also had other problems (I don't plan to file bug reports for > those because I assume that it's too early for that): > * the character set for emails were detected incorrectly, thus > displaying emails with English text with Chinese (?) characters > * After fixing the calendar authentication problem, LDAP started > to show signs of life on the console: for over an hour before I > left I saw log messages about LDAP contacts being downloaded > continuously. I considered killing it as it seemed to download > all contacts, but I decided to give it a chance - perhaps it'll > stop eventually by itself. In the GUI I haven't been able to get > any results so far (another important usage for me). Patrick, The current, MAPI branch, has the hacked up GAL implementation from the evolution-exchange project, which uses ldap, but runs standalone in e-d-s, unlike the other one. Ideally, we must be doing GAL based on libmapi's nspi interface to browse/populate GAL. Then we would be able to do faster lookup, better cache resync, delta fetc etc. But, its again huge effort, so just waiting to get the current one out with the old GAL and take this up later. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Interface Spec for PIM component interoperability
On Wed, 2008-08-20 at 14:14 +0200, Holger Berndt wrote: > Hello Evolution hackers, > > I just subscribed to the list, and browsing the archives this message > may or may not have an overlap with the recent thread about EDS D-Bus > interface in "Future of eds bindings". > > I am a supporter of the desktop independant, GTK+ based MUA Claws Mail. > Its (few) developers are pretty evenly split between between being KDE, > GNOME, and XFCE users. > > I've thought many times that it would be great to have a > (maybe freedesktop.org) standard for PIM component access and > interaction. Ideally, this would allow for all PIM components > implementing this spec to be interchangable without loosing > integration, so the user could choose calendar, addressbook, mailer etc > independantly, and still have a nicely integrated PIM suite. This could > be achieved by defining a "common language" for popular PIM tasks > involving multiple components (by "PIM component", I mean MUA, > calendar, addressbook, notes application etc). Sure, a valid requirement. Evolution gets used by quite a few KDE users, I have received feedbacks from such users on the similar lines. > > Let me give a few examples of such tasks: > What a MUA could request: > - dear addressbook, whoever you might be, please add the following > contact: John Doe <[EMAIL PROTECTED]> > - dear addressbook, please give me a list of all contacts > - dear addressbook, please open up contact xy for editing. Or just show > me your main window. > - dear calendar, whoever you might be, I just received a meeting > invitation via email. Please insert that event into my calendar > > Basically, it would be necessary to define a set of interfaces > (possibly D-Bus services) along the lines of > org.freedesktop.pim.addressbook.storage > org.freedesktop.pim.addressbook.ui > org.freedesktop.pim.calendar.storage > org.freedesktop.pim.calendar.ui > org.freedesktop.pim.mua.storage > org.freedesktop.pim.mua.ui > etc, where in the case of GNOME Evolution could provide the *.ui > interfaces and EDS could provide the *.storage interfaces. > Infact, I'm open to have some defined common interfaces that multiple apps (Mail, Calendar) can interface with the PIM daemons (EDS, Akonadi, etc). Infact, starting next week (planning bits atm), I'm gonna work on moving mail to e-d-s to make EDS complete. Then defining common standards/interfaces (across Mail, Contacts Calendars) would help apps to operate transparently, independent of the desktops. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Future of eds bindings
Ross, > In the case of getChanges(), this is a local operation so just needs to > be fixed. It shouldn't take more than the timeout, even with 10k > contacts. > 10K? I have seen multiple enterprise users books with 100K contacts. I remember some bug where the user had close to a million contacts :(, that might be GAL or GW System addressbook. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
Patrick Evolution follows GNOME release cycles, which has just three dot releases on the stable branch (2.22.3). And after that only for DoS/Vulnerability fixes there will be dot releases. Distros shipping 2.22.x will pick patches from trunk/2.22.x and apply as and when required. (Atleast for OpenSUSE, I/my team does that). Im sure Ubuntu/Fedora too does the same. If it is a really issue, may be mailing the distributors list on picking some patches for Evo/Eds may help. -Srini. On Tue, 2008-08-19 at 18:41 +0200, Patrick Ohly wrote: > Hello, > > I have a question primarily to the maintainers of the various Linux > distributions which include Evolution 2.22.x (Ubuntu 8.04 LTS, Debian > Lenny), but also to the Evolution hackers: the latest stable release, > 2.22.3.1, still contains bugs. There are different ways to deal with > this: > 1. Evolution upstream continues to apply bug fixes to the 2.22.x as > long as important distributions use that. > 2. Maintainers of packages apply patches locally, without or with > help by Evolution upstream. Upstream could help with bug > tracking. > > What's the current practice? It seems that upstream has already stopped > updating the 2.22 branch and bug fixes are only applied to trunk [1]. > > I'm bringing this up because at least one of the bugs will become > critical in September: as noted this week [2], the conversion of system > time zone information into libical time zone information (as used by > Evolution) yields an end of summer time which is one week too early for > Western Europe. It might also be incorrect for other countries and for > the beginning of summer time. > > That's particularly disappointing because the work on improving time > zone support [2] was supposed to solve such issues. Now it looks like > Evolution will fail to display events at the right time - once again! > > In addition to this problem I'm sure there are other bugs which could be > included in another 2.22.x release. The broken Exchange Connector > contact change tracking [1] is one example. > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=546934#c2 > [2] http://bugzilla.gnome.org/show_bug.cgi?id=548268 > [3] http://www.estamos.de/blog/2008/06/22/time-zone-handling-in-evolution/ > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] make dist error in evolution-data-server
intltoolize (GNU intltool) 0.40.0 -Srini. PS: I didn't release 2.23.5 (I was on some training), and Johnny did it. On Wed, 2008-07-30 at 12:05 +0800, Jeff Cai wrote: > Which version of intltoolize did you use? > > Jeff > > Srinivasa Ragavan wrote: > > On Wed, 2008-07-30 at 10:49 +0800, Jeff Cai wrote: > > > >> Gilles Dartiguelongue wrote: > >> > >>> Le mardi 29 juillet 2008 à 14:09 +0800, Jeff Cai a écrit : > >>> > >>> > >>>> $make dist > >>>> make: *** No rule to make target `intltool-merge.in', needed by > >>>> `distdir'. Stop. > >>>> > >>>> I'm curious about how you make it work. > >>>> > >>>> > >>> either it's missing in EXTRA_DIST or you need to run intltoolize --force > >>> (or just use autogen.sh, it does all the dirty first run things) > >>> > >>> > >> intltoolize --force can not produce those files. > >> > >> Srini, how did you produce the tar ball at the release time? > >> > > > > I checkout from svn, do a complete autogen.sh, make install and then I > > do a make dist as everyone. I have never faced it anytime. > > > > -Srini > > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] make dist error in evolution-data-server
On Wed, 2008-07-30 at 10:49 +0800, Jeff Cai wrote: > Gilles Dartiguelongue wrote: > > Le mardi 29 juillet 2008 à 14:09 +0800, Jeff Cai a écrit : > > > >> $make dist > >> make: *** No rule to make target `intltool-merge.in', needed by > >> `distdir'. Stop. > >> > >> I'm curious about how you make it work. > >> > > > > either it's missing in EXTRA_DIST or you need to run intltoolize --force > > (or just use autogen.sh, it does all the dirty first run things) > > > intltoolize --force can not produce those files. > > Srini, how did you produce the tar ball at the release time? I checkout from svn, do a complete autogen.sh, make install and then I do a make dist as everyone. I have never faced it anytime. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] how to send emails from the terminal?
Oh I meant that the current code doesn't support for doing it for contact list. Since the contact lists are loaded on autocompletion only, though expanded during send. -Srini. On Thu, 2008-07-24 at 19:11 -0500, irving vladimir wrote: > yes it is possible, for example I have a list called irvings which > contain my three email addresses from different accounts, so when I > type manually irvings in the 'To' field it appear underlined and with > a coma ( , ) in the end, then when I send it arrive to my three > accounts, but this not happen when I do it from the command line since > the list-name irvings not appear underlined > > thanks. > > 2008/7/20 Srinivasa Ragavan <[EMAIL PROTECTED]>: > I dont think it is possible to send it to a evolution specific > contact > list. The TO/CC/BCC is expected to be exact. > > -Srini. > > > On Sat, 2008-07-19 at 17:41 -0500, irving vladimir wrote: > > Hi, when I try to send a message from the comand line I do: > > > > > > evolution > > > "mailto:[EMAIL PROTECTED]&subject=hi&body=something" > > > > where 'name-list' is the name of a list of contacts that I > have > > created. The problem is that the message never arrive to > anybody. I > > have see that when I type the name of the list manualy the > name > > appears underlined and when I send it the message arrive to > everybody. > > > > I wish to know how to send the message from the comand line > to the > > list of contacts that I have created withoutd having to > write it > > manualy. > > > > thanks. > > > > > > > ___ > > 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 > > > > -- > irving vladimir > ___ > 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] Evolution 2.23.5 , Evolution-Data-Server 2.23.5 , GtkHTML3.23.5 and Evolution-Exchange 2.23.5 released
Hi All,
The Evolution Team is pleased to announce the release of Evolution
2.23.5.
You can download the following :
http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.23/gtkhtml-3.23.5.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/2.23/evolution-data-server-2.23.5.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.23/evolution-2.23.5.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.23/evolution-exchange-2.23.5.tar.bz2
Upgrade Notes :
Evolution 2.23.x is the unstable series of 2.24 development.
What is New ?
=
CAUTION: We have merged Camel DB Summary based on sqlite with this
release. It has a migration code for 2.22.x, but for 2.23.4 users, it
wont be invoked, but the code is to auto migrate on demand which might
be a bit slow. It should be fairly stable, with a lot of known issues.
Search is partial atm. VFolders aren't fully functional and the
unread/total counts are messed up a bit and a lot more. Please add all
the bugs you see due to this to the tracker bug
http://bugzilla.gnome.org/show_bug.cgi?id=543389
Non-default old camel providers may not work with 2.23.5 , like imap4 or
evolution-brutus etc.
Evolution:
==
New in 2.23.5
Camel DB Summary support. (Srinivasa Ragavan & Sankar P)
New EPlugin for message templates. (Bharath Acharya & Diego Escalante
Urrelo)
Google Contacts support (Jörgen Scheibengruber)
Bug Fixes:
#543753: Addressbook error string fixes (Andre Klapper)
#228725: Contacts view should not say "no items in this view" until the
backend is done responding (Milan Crha)
#543134: Mail notification plugin should provide a right-click menu for
preferences (Milan Crha)
#269152: Work-around for MS Outlook/Lookout that use X-MimeOLE (Milan
Crha)
#200147: Added basic Template support (Bharath Acharya)
#206592: Action to invoke New Message window from the composer itself
(Milan Crha)
#207802: Do not allow drop messages to the same message list as is the
source. (Milan Crha)
#243201: Escape rule title so that can contain also XML entities in the
file (Milan Crha)
#310988: Don't even show the "send-options" action unless an Exchange
or GroupWise account appears in the From combo box (Matthew Barnes)
#318089: Ask for destination source only when have more than one
writable source defined (Milan Crha)
#329821: Show tooltips over task's table (Milan Crha)
#368038: Ensure only one Birthdays & Anniversaries source (Milan Crha)
#370731: (Novell Bugzilla) Use MAX to determine the minimal size for
each cell. This prevents the numbers and day-names from getting fuzzy when
using large font-sizes (Suman Manjunath)
#382783: Grab focus of new rule part on adding and scroll to the bottom
too (Milan Crha)
#395636: Added accel key Ctrl+Shift+B for collapsing all threads and
Ctrl+/ for marking all messages as read (Roshan Kumar Singh)
#423395: Put the anchor where the message body begins and let GtkHTML
know the anchor name to place the cursor there in caret mode on the first focus
(Milan Crha)
#440818: Convert line to UTF-8 if not a valid one. Pretend it to be an
ISO-8859-1 line (Rodrigo Castro)
#477082,#438479: Fixed documentation (Andre Klapper)
#478469: Changed the progress dialog to be more HIG compliant (Milan
Crha)
#519536: Handle freeing of data safely. (Srinivasa Ragavan)
#524130: Pass description text through 'camel_text_to_html' to have
links clickable in a preview (Milan Crha)
#526262: Handle _title element in analogical way as title (Maciej
Piechotka)
#530069: Don't show the configuration tab unless the selected plugin
actually has configuration options (Matthew Barnes)
#532472: Strip the account URL (via CAMEL_URL_HIDE_ALL) before
comparing it to the already-stripped 'transport_url', to avoid unnecessary
password prompts (Matthew Barnes)
#532597: Do not leave selected more than one item if somebody else took
care or reposition of the cursor row before the delete (Milan Crha)
#534039: Track folders even when Search Folders disabled, to have them
known when enabling Search Folders on demand (Milan Crha)
#536488: Remove '~/.evolution/.running' file before backup/after
restore, thus Evolution will not claim next start it was closed incorrectly
(Milan Crha)
#537275: Do not pass data to the child structure if we were canceled
(Milan Crha)
#537725: Set the autosaved flag so we don't get pestered with a save
dialog if the user then decides to close the composer window (Matthew Barnes)
#538741: Strip preceding tabs from Date headers too (Paul Bolle)
#538908: Desensitize the "send-options" action unless we've selected as
Exchange or
Re: [Evolution-hackers] how to send emails from the terminal?
I dont think it is possible to send it to a evolution specific contact list. The TO/CC/BCC is expected to be exact. -Srini. On Sat, 2008-07-19 at 17:41 -0500, irving vladimir wrote: > Hi, when I try to send a message from the comand line I do: > > > evolution > "mailto:[EMAIL PROTECTED]&subject=hi&body=something" > > where 'name-list' is the name of a list of contacts that I have > created. The problem is that the message never arrive to anybody. I > have see that when I type the name of the list manualy the name > appears underlined and when I send it the message arrive to everybody. > > I wish to know how to send the message from the comand line to the > list of contacts that I have created withoutd having to write it > manualy. > > thanks. > > > ___ > 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] camel-db-summary changes merged to Trunk
Jules, We would bump the camel version numbers, not sure why e-d-s. pc. Also, I might take some time to do it, things broken and me/sankar are really busy. -Srini. On Wed, 2008-07-16 at 16:12 +0200, Jules Colding wrote: > On 16/07/2008, at 20.33, Sankar wrote: > > > Hi , > > > > As many of you know, Srini and I were working on a branch > > camel-db-summary (codenamed Madagascar). > > > > This is now merged with trunk. Please see > > http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=9125 > > Will you increment "Version:" in "evolution-data-server-1.2.pc", please? > > 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
[Evolution-hackers] Evolution: Taking forward...
Hello guys, We have had a set of problems that we are carrying around for some time like : * Copyright assignments, which is not the best way looking for the future of Evolution. It sucks and sort of limits contributions to Evolution and we wanted to drop it. * The current licensing incompatibility issues of Evolution with Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the new mapi based connector being developed for Exchange 2007. So here is the plan : * Drop Evolution copyright assignments and make it really easy to contribute to Evolution * Move Evolution licensing to "LGPL v2 and LGPL v3" to let us re-use the code more easily around the platform. This also moves us closer to Thunderbird's MPL/LGPL model. We think this is good for Evolution and (of course) we continue to invest in Evolution. We are also working to ensure we have the rights to re-license all of the code. We will do the licensing/header changes as we audit the code ownership situation. It would be really helpful if you can post a public/explicit mail with permissions to do it, or code pointers - if you think you wrote a piece of Evolution code & object. We are really excited about this and we feel this would really help Evolution a lot. We need your support now for making this change and to take Evolution to great heights. Thanks for your contributions and support. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] today's evolution userdocs update.
Updated tarball at http://ftp.gnome.org/pub/GNOME/sources/evolution/2.22/evolution-2.22.3.1.tar.gz Unfortunately, this passed my make distcheck and our QA's build sanity test won't capture this, which sort of made it difficult to catch it before the release. -Srini. On Mon, 2008-06-30 at 15:29 +0200, Andre Klapper wrote: > Dear Evolution Team. > > Thanks for not testing the integrity of the changed userdocs file. > Thanks for removing too much markup, though required to compile. > Thanks that this means 2.22.3 does not compile out of the box, see > http://bugzilla.gnome.org/show_bug.cgi?id=540918 . > Thanks for not testing the tarballs you release. It's not the first > time. > Thanks for getting the docs update committed to svn 5 hours before > tarballing, so no translators could update their translations. > Again, thanks for not proofreading anything in evolution.xml - thanks > for keeping the error rate constant, and people in work. Translators > love to update their translations frequently everytime you commit some > spelling fixes and introduce some new ones. > > I'm pretty fed up with wasting my time and repeating the same stuff > over and over again, and getting answered that it won't happen again. > > Now one may come up with other conclusions, but Novell IS capable to > handle the user docs. I was told that in > http://bugzilla.gnome.org/show_bug.cgi?id=435942#c41 . That is a good > feeling that lets me sleep warm and comfortable, without any worries. > > So long, and thanks for all the fish. > > Yours sincerely, > andre ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI branch status?
On Tue, 2008-06-17 at 08:50 +0530, Suman Manjunath wrote: > On Mon, Jun 16, 2008 at 6:26 PM, Srinivasa Ragavan <[EMAIL PROTECTED]> wrote: > > Andre, the development is on track and we are moving inline with the > > libmapi-0.7. Some things are pending/in-progress are > > > > > (*) free busy lookup > Oops, Sorry I meant "Creating Meetings" -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI branch status?
[Removing r-t list as it may not be right continue including them on user queries ] On Mon, 2008-06-16 at 14:09 +0100, William John Murray wrote: > Hello Srini, > I could just point out that I cannot read my email with it. > Only half the folders are shown, and these happen not to include my > inbox. Should I open a bug? I felt it was 'work in progress' but > you seem to imply it should be better than that. Ideally, it should be working. IIRC our schedule has gone past that stage and such bugs should be killed early. Make sure that Johnny has that on top of his list ;-) But, don't file a bug, we dont have any component for that and we dont want to have anything official till we resolve the licensing, really sorry to say that. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI branch status?
On Mon, 2008-06-16 at 12:45 +0200, Andre Klapper wrote: > Hi Evolution team, > > can somebody please update me/us about the current state and plans for > the Evolution MAPI branch? Andre, the development is on track and we are moving inline with the libmapi-0.7. Some things are pending/in-progress are (*) mime parsing (*) free busy lookup (*) Delta fetching for addressbook. So the provider as a whole is sort of ready to use, but lots of minute things like these are really taking time, also due to tight schedule of libmapi also we had to post pone/wait till they get available. > Haven't seen a lot about this in the last > weeks and would be interested to know about potential problems and > whether we can except this to be included in GNOME 2.24 (customer > expectations; GNOME release notes; ). As of now, we know Evolution needs to move to a GPL V3 compatible license and we had made a proposal to the legal team, and it seems to take lot of time due to the effects it can cause. Lots of things like copyrights, etc are being analysed and it is approaching the end point, but not yet there :( I'm not very hopeful for GNOME 2.24, which is just a month or so away from freezes. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] time zone problem: extending API in stable branch?
Patrick, Can you just point us to the right patch, that extends API ? I seem to hit the wrong patch. I dont see any .h changes also. Is there a way, we can work around for stable branch alone? We may need release team approval, if we have to update API (I guess so, though EDS isn't part of platform, we may have to atleast check with them) -Srini. On Thu, 2008-06-12 at 22:25 +0200, Patrick Ohly wrote: > Hello, > > the patch that I am suggesting to fix the time zone issues in Evolution > (see http://bugzilla.gnome.org/show_bug.cgi?id=528902) adds new > functions to libecal. Note that the extended library is backwards > compatible, i.e., this is not an API change which requires recompiling > other programs (http://bugzilla.gnome.org/attachment.cgi?id=112638). > > Is this an acceptable solution for the 2.22.x stable branch? Chentill > reviewed the patch and agreed to committing it on trunk after some minor > changes (which I have done in the meantime), but he is concerned about > the API and rather would like to keep this out of the stable release. > > I'm writing here to also get the opinion of Evolution packagers who > might not monitor the discussion taking place in the bug tracker. Is > this issue important enough to extend the API in the next 2.22.x > release? If Evolution upstream doesn't include it in 2.22.x, are > distributions going to apply the patch (it is written against the stable > branch and applies cleanly) anyway? > > I personally think that this is important because Evolution will > continue to use out-dated time zone definitions for new meetings in > perpetuity unless people wipe out their old calendars or the patch is > applied. Quoting Paul Smith, who missed a meeting this spring due to > this bug: > I have to add my voice to those saying "please, please, PLEASE > someone fix this complete and utter disaster! > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution and ldap contacts
On Fri, 2008-06-06 at 11:17 +0200, Thomas Vander Stichele wrote: > Hi, > > I've been trying in my spare time to dip my feet in the LDAP contacts > backend because, well, there's lots of stuff that it does wrong for me > to the point where it's close to unusable in my real life use. > > I'm starting small, and I have some questions that I've already asked > various people IRL or on IRC, but nobody seems to have a good idea, so I > thought I'd join and ask here instead. > > 1) Does anyone know why the LDAP backend first does an anonymous bind > (which my servers for obvious reasons don't allow) to decide if the > server is up at all ? I don't see the point of not using the credentials > configured here. If the credentials are there already, it may not make sense to do a anon bind. But I donno much history behind the code there. > > 2) Is there anything in evolution checeking the > GNOME_Evolution_Addressbook_CallStatus returned from some of the calls ? > It is hugely annoying to not have any clue at all *why* a contact > backend fails. It got slightly better in evo 2.22 (which shows "Error > loading addressbook" in the widget you get when you click To/CC/Bcc) but > not by much. Where should I go dig in the Evolution code to show some > useful error messages because of CallStatus returns ? The best bet is to debug out from EDS. Generic error returns from eds are shown with that message iirc. See where it returns that message and pro'lly you 'll know there. > > 3) One of the possible reasons of failure for an LDAP backend is not > having the certificate installed, which is an especially important part > to warn about and provide a solution for. Should I reuse an existing > CallStatus (like AuthenticationFailed) or add one for this case ? > You can use it. > 4) Anyone have an idea why right-clicking on an address in a mail, > adding it to addressbook, then selecting an LDAP backend, claims that > the backend is readonly, while it works fine when I go to it in the > contacts view ? My eds debug console shows no LDAP activity meanwhile, > it's not even trying to write to the LDAP server. This is new in 2.22 - > I didn't have this behaviour in previous releases. > You can look at addressbook/gui/contact-editor/e-contact-quick-add.c:merge_cb that seem to emit the error. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Crasher in evolution-exchange
On Mon, 2008-06-02 at 10:19 -0400, Paul Smith wrote: > Hi all; can someone take a look at this bug: > > http://bugzilla.gnome.org/show_bug.cgi?id=532844 Done. Thanks to Bharath. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 2.23.3.1 no delete shortcut?
File a bug and CC me. I'll make sure that there are no regressions in it. -Srini. On Tue, 2008-06-03 at 11:51 -0400, Daniel Gryniewicz wrote: > Yep, that's it. Reverting 35570 fixes the problem, and makes ctrl-d > delete messages again. > > Dan > > On Tue, 2008-06-03 at 11:23 +0530, Srinivasa Ragavan wrote: > > But that was added to keybindings section, which was only my commit. > > > > -Srini. > > On Mon, 2008-06-02 at 23:27 -0400, Daniel Gryniewicz wrote: > > > I'm guessing it was revision 35571, which removed > > > accel="*Control*d" > > > from ui/evolution-mail-message.xml entirely. This is just a guess, tho. > > > > > > Dan > > > > > > On Tue, 2008-06-03 at 08:32 +0530, Srinivasa Ragavan wrote: > > > > No, It shouldn't. Did I broke something? I definitely hacked some code > > > > around delete, but sure that it worked well. > > > > > > > > -Srini > > > > On Mon, 2008-06-02 at 21:56 -0400, Daniel Gryniewicz wrote: > > > > > Is it my imagination, or does 2.23.3.1 not have any keyboard shortcut > > > > > for delete? Ctrl-D seems to open a save dialog now, rather than > > > > > delete. > > > > > > > > > > Dan > > > > > > > > > > ___ > > > > > 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] 2.23.3.1 no delete shortcut?
But that was added to keybindings section, which was only my commit. -Srini. On Mon, 2008-06-02 at 23:27 -0400, Daniel Gryniewicz wrote: > I'm guessing it was revision 35571, which removed > accel="*Control*d" > from ui/evolution-mail-message.xml entirely. This is just a guess, tho. > > Dan > > On Tue, 2008-06-03 at 08:32 +0530, Srinivasa Ragavan wrote: > > No, It shouldn't. Did I broke something? I definitely hacked some code > > around delete, but sure that it worked well. > > > > -Srini > > On Mon, 2008-06-02 at 21:56 -0400, Daniel Gryniewicz wrote: > > > Is it my imagination, or does 2.23.3.1 not have any keyboard shortcut > > > for delete? Ctrl-D seems to open a save dialog now, rather than delete. > > > > > > Dan > > > > > > ___ > > > 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] 2.23.3.1 no delete shortcut?
No, It shouldn't. Did I broke something? I definitely hacked some code around delete, but sure that it worked well. -Srini On Mon, 2008-06-02 at 21:56 -0400, Daniel Gryniewicz wrote: > Is it my imagination, or does 2.23.3.1 not have any keyboard shortcut > for delete? Ctrl-D seems to open a save dialog now, rather than delete. > > Dan > > ___ > 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] evolution-data-server 2.23.2 build error: e_file_cache_get_type is not defined
http://bugzilla.gnome.org/show_bug.cgi?id=533780 ? -Srini. On Fri, 2008-05-30 at 12:28 +0800, Jeff Cai wrote: > evolution-data-server-2.23.2/docs/reference/calendar/libedata-cal > cc -i -xO4 -xspace -xstrconst -xpentium -mr -xregs=no%frameptr -i -xO4 > -xspace -xstrconst -xpentium -mr -xregs=no%frameptr -I/usr/include/mps > -I/usr/include/mps -Wl,-zignore -Wl,-zcombreloc -Wl,-Bdirect > -o .libs/libedata-cal-scan .libs/libedata-cal-scan.o -L/usr/lib > -L/usr/lib/mps ../../../../calendar/libedata-cal/.libs/libedata-cal-1.2.so > /export/home/caiqm/packages/BUILD/SUNWevolution-data-server-2.23.2/evolution-data-server-2.23.2/calendar/libecal/.libs/libecal-1.2.so > > /export/home/caiqm/packages/BUILD/SUNWevolution-data-server-2.23.2/evolution-data-server-2.23.2/libedataserver/.libs/libedataserver-1.2.so > -ldl -lplc4 -lplds4 -lnspr4 -lsoup-2.4 > ../../../../libebackend/.libs/libebackend-1.2.so -lxml2 -lgnome-2 -lpopt > -lbonobo-2 -lbonobo-activation -lORBit-2 -lgio-2.0 -lgmodule-2.0 > -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgconf-2 -lglib-2.0 > -R/usr/lib -R/usr/lib/mps > creating libedata-cal-scan > gtk-doc: Running scanner libedata-cal-scan > ld.so.1: libedata-cal-scan: fatal: relocation error: file > evolution-data-server-2.23.2/calendar/libedata-cal/.libs/libedata-cal-1.2.so.6: > symbol e_file_cache_get_type: referenced symbol not found > > > ___ > 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] Switching the current folder from a plugin
You need to look at em-folder-tree.c. That holds the code. -Srini. On Wed, 2008-05-28 at 14:58 -0700, Paarvai Naai wrote: > Hi all, > > I'm hoping that somebody on this list will have a quick answer to this > question. I am currently writing a plugin that manipulates folders in > Evolution. I was able to figure out how to move messages between > folders, but was not able to find the required API calls to make > Evolution switch the current folder view in the GUI. I'd like the > behavior to be as if the user clicked on a folder in the tree. If > anyone can point me in the right direction, the help would be much > appreciated. > > Thanks, > Paarvai > ___ > 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] Evolution Calendar / memeos/ tasks summary windows appear black in colour at startup!!
On Wed, 2008-05-28 at 14:51 +0530, svalbard colaco wrote: > Hi all; > > I have evolution on DirectFB and in my calendar view / memo view / > task view/ windows ; > The side bar for the calendar /memos/ tasks summary window appears > black in color at first; > But when i click on them it appears white and editable as > expected...Everytime i start up Evolution > These summary windows appear black in the above mention Evolution > components. > > What could be the reason for this? I have no idea about this. May be someone who know DirectFB/Gtk+ stuff could help you better. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Query
Amit, Send a mail to [EMAIL PROTECTED] He shares most of the NOSIP load now-a-days. -Srini. On Wed, 2008-05-21 at 18:20 +0200, Rodrigo Moya wrote: > Hi Amit > > Forwarding your mail to the evo-hackers list, where you'll get a better > answer > > cheers > > On Mon, 2008-05-19 at 15:53 +0530, amit gupta wrote: > > Sir, > > I am a student of B-Tech. My branch is Electronics and > > Comunication. I want to the Project work on Evolution. I had seen your > > website site in this site i saw these three things: > > > > What do you have to bring to Novell? > > > > 1. Original Letter from your HOD stating your name and the duration > > of the projects if this is an academic project. > > > > 2. "Novell Open Source Internship Program" agreement signed by you and > > your parent / guardian. One per person. > > > > 3. Project specific Copyright Agreement form for each project which > > has to be filled accordingly and signed. One per person. > > > > With these three documents, come to Novell, with the project decided > > tentatively. > > > > > > I want to know that "How can i submit the Project-specific > > Copyright Agreements Form and where will i found this form in your > > website?" I have two letters one is Contributors Acceptance Letter and > > second is HOD Letter. I can send signed copy of these two letters. > > > > Please give the information about Project-specific > > Copyright Agreement Form. > > > > > > Thanking you > > > > Amit Gupta ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution LDAP backend
On Fri, 2008-05-16 at 08:55 +0200, Free Ekanayaka wrote: > > Evo ldap backend was nothing but, openldap patched ntlm. But there was > > no update to it, as most distros patch OpenLDAP with ntlm and ship it. > > > Thanks, do you know of any documentation about using evolution with > ntlm? > What do you mean by that? -Srini. > Ciao, > > Free > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution LDAP backend
Evo ldap backend was nothing but, openldap patched ntlm. But there was no update to it, as most distros patch OpenLDAP with ntlm and ship it. On Thu, 2008-05-15 at 17:12 +0200, Free Ekanayaka wrote: > Hi all, > > has anybody used the evoldap backend to set up a default LDAP > address book? > > The LDAP backend for evolution mail accounts works great, I just > followed the instructions here: > > http://live.gnome.org/Evolution_2fGConfLDAPBackend > > and everything worked as expected. > > However I was not able to set a default LDAP address book. I have > tweaked /etc/gconf/2/evoldap.conf in various ways, and I can make it > set the /apps/evolution/addressbook/sources variable with the values > I want, got from an LDAP query. However evolution keeps overwriting the > variable with its own default values. > > It feels like something wrong with the $(EVOLUTION_UID) value that the > evoldap backend uses to set the variable. > I have no idea about the gconf-ldap backend. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Loading of Icons in Evolution
On Tue, 2008-05-13 at 18:16 +0530, svalbard colaco wrote: > Hi all; > > > 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 What icons are n't appearing. Name a few, I can tell you where they reside. -Srini > > $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? > > > Any links or pointers in this regard will be of great help. > > Thanks & Regards > sv. > ___ > 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] Error storing summary.
Sankar, Yet another solution for this problem will be to (re)write the local backend using the camel-offline-folder model, where every mail in the folder is stored in a distributed fashion, avoiding one huge mbox or huge files in a directory and also solves issues like unlink the file to delete a mail etc. -Srini On Mon, 2008-05-12 at 14:51 +0530, Sankar P wrote: > On Fri, 2008-05-09 at 23:57 +0200, Andre Klapper wrote: > > OK, so i managed to fuck up my POP Inbox for the third time in a few > > weeks, means: every time i switch to another folder i now get an "Error > > storing summary" (or something like that). i've seen some reports about > > this in bugzilla, e.g. > > http://bugzilla.gnome.org/show_bug.cgi?id=532049 . the last time i ran > > into this psankar told me to manually edit the mbox file and remove the > > offending email that misses the From line. this is not fun anymore when > > having a 600MB inbox file. a normal user is not willing to learn vim and > > emacs, me neither. > > I guess there should have been some recent commit which catalyzes this > break-up-of-mbox. So, we need to just analyze and find out on what > scenarios this is caused. > > Earlier, we used to get a folder-summary-mismatch and will not proceed > at all. I have seen some heavy users being saved from that trouble, once > we put in the code to auto-fix the .summary file. > > Broken mboxes are one scenario which we have not handled so far and it > will be fixed. May be we will provide: evolution-fix-broken-mbox which > will handle them. (/me remembers fejj's mail sent 2 days back) > > However, there are certain important things than fixing broken mboxes, > like moving the summary to a db so that you don't have to hold every > msginfo etc. which we are currently working on. So, operations like mbox > recovery will have to wait for some time. We will try to identify why > this has started happening frequently for you and will fix this soon, > probably tracked in a bgo bug. > > > > Philip, > > Converting the local store from mbox to maildir will be a better option > for the local accounts. It might create new problems and I will analyze > about this and will come up with a fix if it does not cause any issue. > > And sqlite databases disk-blocks aren't spectacularly closely-written, > when I last iogrinded (ground?) them. And mboxes/maildir are readable by > all sane mail clients and hence makes sense to stick to some common > standard than a single-filed-db. May be I will make a study of this > after the db-based summary work is done. > > > > if nobody's working on a fix i should consider > > switching to thunderbird. > > We will fix this bug as it is critical and comes from a long time user, > whom we want to keep happy :-) However, mail is a hog that tends to bite > if it exceeds a limit, no matter which application we use and we will > try to tame the beast. > > > > > andre > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] HOW TO HANDLE: Glib-GObject-WARNING :Invalid cast from GdkPixmap to GdkWindow.
I think it was due to some code issues and I remember some one else complained it on a normal case also. See if you have the icons loaded at the right place. -Srini. On Mon, 2008-05-12 at 11:01 +0530, svalbard colaco wrote: > > > Hi all, > > I've ported my application on DirectFb backend ; It gets rendred fine > but some menu icons are not displayed > It gives an 'X' for some of the icons in the tool bar and the menu > bar. > > Is it anything to do with the following warning?? > > > > How to handle such a warning? What colud be the reason for such a > warning? > > > > > ___ > 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] default bug handling policy
Hello Patrick, On Mon, 2008-05-05 at 20:25 +0200, Patrick Ohly wrote: > Hello, > > are bugs discovered on the trunk also fixed on the latest maintenance > branch by default or only if someone asks for it? Different projects > handle this differently. We backport to stable branch, if they don't break any freezes like UI/String/API/ABI. If we find the fixes a bit risky, we dont put them to stable, or atleast wait for a dot release on the unstable trunk. > > I personally prefer to apply fixes to the maintenance branch, then port > them forward to the trunk automatically. In my experience that reduces > the risk of "forgetting" fixes. But there are valid arguments for both > positions; I just want to know where Evolution stands, not start a > discussion. > Most of the hackers work on the trunk and back port the fixes to stable branch. But user/other-hackers who use stable release make patches on stable release and while committing we forward port to trunk also. > I (incorrectly?) assumed that for Evolution patches would be manually > applied to all affected and maintained branches, but at least in one > case that I just ran into ([1], [2]) this wasn't done. Because I didn't > check the code on the trunk I needlessly ended up fixing the memory leak > on the 2.22.x branch again. > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=531197 > [2] http://bugzilla.gnome.org/show_bug.cgi?id=523541 > May be it is missed or kept pending, other wise I dont see any reason why not to. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libdb from EDS source
Ross, 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: - Berkeley's libdb - 3.1.17 db3 is available from http://www.sleepycat.com. Make sure to get 3.1.17, it isn't the latest version. --- IMPORTANT WARNING --- The on-disk format of DB files has been changing between versions 2, 3 and 4. Also, because of the libdb API, there is no way to easily handle the different formats from within the application. For this reason, Evolution has chosen to use one specific version of the library (version 3) and stick to it, so that users do not need to convert their addressbook files to use them with different version of Evolution. That's why Evolution REQUIRES libdb 3.1.17, and NO OTHER VERSION. If you force the check to accept a version different from 3.1.17, your binary of Evolution will be using a different format from the chosen one; this means that it will not be able to read addressbook databases created by other versions of Evolution which were compiled in the standard way. Also, we DO NOT GUARRANTEE that Evolution will work with different versions of libdb at all, even if it can be trivially made to compile against them. SPECIAL NOTE FOR BINARY PACKAGERS: If you are making binary packages for end-users (e.g. if you are a distribution vendor), please statically link Evolution to Berkeley DB 3.1.17, as mandated by the configure.in check. DO NOT patch configure.in to work around the check. Forcing the check to link to a different version of the library will only give headaches and pain to your users, who will see their addressbook disappear and will complain to us (the Evolution team) about losing their data. Besides, libdb will be linked statically, which means that your distribution doesn't actually need to ship DB 3.1.17 itself separately. The Evolution team will be infinitely grateful for your co-operation. Thanks. This proved quite painful for distros (hanging on to a specific version) though so we moved it inside e-d-s eventually. That way we always had a known quantity. === Ross, if we have an answer for this, we can close on this immediately. -Srini. On Fri, 2008-04-25 at 08:46 +0530, Srinivasa Ragavan wrote: > Ross, > > IIRC, it was done because, every libdb update broke Evolution or libdb > wasn't so stable release over release. Also OpenSUSE uses statically > linked libdb. But most of the hackers I know, dynamically link libdb. > I'm favor of the change. But lemme ping some old evolution hackers who > were part of this change, to understand what they feel about it. > > -Srini > On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote: > > Hi, > > > > I think that we should remove the fork of Berkeley DB from the Evolution > > Data Server source. Debian, Ubuntu, Gentoo and Fedora all use > > --with-libdb to dynamically link to a system library, so it is known to > > work. > > > > This would involve removing libdb from svn, and always dynamically > > linking to libdb instead. --with-libdb would still exist for people who > > want to use a custom libdb, but it would default to /usr. > > > > Thoughts? > > > > Ross > > ___ > > 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] Event handling in Evolution.... Need urgent help
On Mon, 2008-04-28 at 18:41 +0530, svalbard colaco wrote: > Hi all; > > Can any one explain to me how events are handled in Evolution? Do > they make use of the libbonoboui wrappers to handle the button events? Sort of: yes. We add the menu items through the xml file and attach call backs to the menu commands in the code. > > Like if i click on the Menu bar ->File menu option->New Mail compose > option ; What will be the event called...? Rather wer in the code > should i look in for this event handling? Look at shell/e-user-creatable-items-handler.c -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libdb from EDS source
Ross, IIRC, it was done because, every libdb update broke Evolution or libdb wasn't so stable release over release. Also OpenSUSE uses statically linked libdb. But most of the hackers I know, dynamically link libdb. I'm favor of the change. But lemme ping some old evolution hackers who were part of this change, to understand what they feel about it. -Srini On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote: > Hi, > > I think that we should remove the fork of Berkeley DB from the Evolution > Data Server source. Debian, Ubuntu, Gentoo and Fedora all use > --with-libdb to dynamically link to a system library, so it is known to > work. > > This would involve removing libdb from svn, and always dynamically > linking to libdb instead. --with-libdb would still exist for people who > want to use a custom libdb, but it would default to /usr. > > Thoughts? > > Ross > ___ > 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
