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] 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] 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] 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
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
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 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 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
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] 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] 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] 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] 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] 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 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] 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
[Evolution-hackers] Evolution Alarm UI
Hey guys, I have been working on some changes to the alarm notification with chen and chax. As part of this im planning to do some changes and attached some UI screenshots. *Proposal* - Alarm Daemon must can start independently, via a .desktop file in the panel menu, so that it can be started independent of Evolution. - There will be a option in Evolution to say that whether to start alarm automatically with evolution or not. - Alarm starts with a tray icon, and has provisions to quit, change configurations. In the configuration gui, the user can select, which calendars, notifications are required. Only for the selected calendars the user will get notifications. http://www.gnomebangalore.org/?q=system/files&file=/preferences_0.png - No more Popup notifications, if libnotify is installed. When the alarm has to be indicated, a desktop notification would be send, stating the subject, location, time (duration). http://www.gnomebangalore.org/?q=system/files&file=/notification_0.png - In addition to that, when ever there is a alarm, the tray icon, has a blinking '!' in it and the tool tip stating the Subject, time (duration). http://www.gnomebangalore.org/?q=system/files&file=/tooltip_0.png If there are more than one alarm, it says the number of alarms. On click of that, the blink would be gone and the regular popup will appear stating everything. Please feel free to provide your comments. Im eager to include new things into this. Thanks Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Alarm UI
On Mon, 2005-10-10 at 18:19 +0100, Calum Benson wrote:
> On 10 Oct 2005, at 10:42, Srinivasa Ragavan wrote:
>
> > - Alarm starts with a tray icon, and has provisions to quit, change
> > configurations. In the configuration gui, the user can select, which
> > calendars, notifications are required. Only for the selected calendars
> > the user will get notifications.
> > http://www.gnomebangalore.org/?q=system/files&file=/preferences_0.png
>
> I'd say this might fall foul of the current HIG guidelines on
> notification icons, although admittedly they're (a) unfinished, and
> (b) a bit crap so far. I'd view anything that puts an icon in the
> tray all the time, but which isn't constantly animating in response
> to some change (like a network connection, resource monitor or
> battery charge), with a little apprehension.
>
Calum, i used these icons, since only these were available. Probably, we
can have a different icon altogether to indicate alarms.
> > - No more Popup notifications, if libnotify is installed. When the
> > alarm
> > has to be indicated, a desktop notification would be send, stating the
> > subject, location, time (duration).
> >
> > http://www.gnomebangalore.org/?q=system/files&file=/notification_0.png
>
> Might be nice to retain the Dismiss/Snooze functionality that you
> currently get with alarm popups... not sure exactly what libnotify
> supports here, and I know we don't have any HIG guidelines for this
> sort of thing yet, but I know Ubuntu's update manager notifications
> offer some sort of options. ("Remind me later" and "Don't tell me
> again", or something.)
>
When you l-click on the blink you get the same old dialog, which
provides the information with snooze/Dismiss functionality. Probably, we
should add, once libnotify does support for those.
> > - In addition to that, when ever there is a alarm, the tray icon,
> > has a
> > blinking '!' in it and the tool tip stating the Subject, time
> > (duration).
> > http://www.gnomebangalore.org/?q=system/files&file=/tooltip_0.png
>
> Would like to think we could invent something a little more
> imaginative than a blinking "!"... randomly blinking things can be an
> accessibility issue (although I think there are some discussions in
> bugzilla about how to handle various DEMANDS_ATTENTION type-things in
> an accessible way). Also, "!" tends to suggest "error", to me, at
> least-- it looks more like "I've lost the connection to your
> calendar" than "you have a reminder".
>
Hmm nice thinking :-). As i said again, we can look at different icons.
For
normal - Existing.
one alarm - Clock with Alarm
multiple - A different indication with from the previous one.
> > If there are more than one alarm, it says the number of alarms.
> Hmm, do you have a screenshot of that? Sounds like it could be a lot
> of information to cram into a small icon.
Hmm, it is the same as of now, the same blink, just the tooltip says
that 'you have %d alarms'. We should replace them with better icons
which is pending.
>
> Cheeri,
> Calum.
>
thanks calum for your inputs.
-Srini
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Alarm UI
On Mon, 2005-10-10 at 16:08 +0530, Harish Krishnaswamy wrote: > On Mon, 2005-10-10 at 15:12 +0530, Srinivasa Ragavan wrote: > > Hey guys, > > > - Alarm Daemon must can start independently, > How are accounts that require authentication (and whose passwords are > not remembered) > handled when evo is not already running ? It shares the session with evo i guess. At any cost, it wont prompt for password from tray icon :-). It wouldnt alarm those events, > > > - There will be a option in Evolution to say that whether to start alarm > > automatically with evolution or not. > > > Is this option like - > 'when-you-launch-evolution-and-find-notify-not-running-start-it' - > yes/no ? > ATM, Evolution users do not have a choice but don't seem to complain > either. Yeah. If it runs, this just ignores. > > - Alarm starts with a tray icon, and has provisions to quit, change > > configurations. In the configuration gui, the user can select, which > > calendars, notifications are required. Only for the selected calendars > > the user will get notifications. > > http://www.gnomebangalore.org/?q=system/files&file=/preferences_0.png > > > Selection as in 'enabled in Evolution calendar' or 'selected for > notifications' ? > I do not recall this coming up in our earlier discussions - but if you > mean the latter, you will > need a per-ESource notification status bit in gconf and handle the > authentication problem > here as well. Harish, this per esource. it maintains in evolution/calendar/notify/calendars. This maintains a 1-1 list. When a new calendar is added, it has to be added by default to this list as enabled for alarm. Thatz there in the plan as of now. > > - No more Popup notifications, if libnotify is installed. When the alarm > > has to be indicated, a desktop notification would be send, stating the > > subject, location, time (duration). > > > > http://www.gnomebangalore.org/?q=system/files&file=/notification_0.png > > > I like this very much :-) > > - In addition to that, when ever there is a alarm, the tray icon, has a > > blinking '!' in it and the tool tip stating the Subject, time > > (duration). > > http://www.gnomebangalore.org/?q=system/files&file=/tooltip_0.png > > > > If there are more than one alarm, it says the number of alarms. On click > > of that, the blink would be gone and the regular popup will appear > > stating everything. > > > > Please feel free to provide your comments. Im eager to include new > > things into this. > Hoping to see the new-look Evolution editor soon as well :-) Harish, correct it :-). It is new-look Evolution Calendar Event/Task/Meeting Editor. This may mean something different ;-). Its on the stack. Im revamping the gui with toolbars, menus, and planning to provide a view functionality as well. Pro'lly ill post some screenshots next week. Im off for rest of the week. > > thanks Srini, > Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution Alarm UI
>>> Sarfraaz Ahmed <[EMAIL PROTECTED]> 10/11/05 1:02 PM >>> On Tue, 2005-10-11 at 08:05 +0530, Srinivasa Ragavan wrote: > On Mon, 2005-10-10 at 16:08 +0530, Harish Krishnaswamy wrote: > > On Mon, 2005-10-10 at 15:12 +0530, Srinivasa Ragavan wrote: > > > Hey guys, > > > > > - Alarm Daemon must can start independently, > > How are accounts that require authentication (and whose passwords are > > not remembered) > > handled when evo is not already running ? > It shares the session with evo i guess. At any cost, it wont prompt for > password from tray icon :-). It wouldnt alarm those events, >Why shouldnt the alarm popup for passwords ? The backends are anyway >enabled for authentication, expecting the clients to request for >authentication. It is not wise to popup for 'n' passwords for corresponding accounts standing from the applet. And i dont think people would prefer that, since when evo starts, it shares the session with evo. > > > > > - There will be a option in Evolution to say that whether to start alarm > > > automatically with evolution or not. > > > > > Is this option like - > > 'when-you-launch-evolution-and-find-notify-not-running-start-it' - > > yes/no ? > > ATM, Evolution users do not have a choice but don't seem to complain > > either. > Yeah. If it runs, this just ignores. I am a bit confused on the assumption here. Will alarm notify be running by default ? If yes, then i guess the option is something like "start alarm notify with evolution - yes/no". Please correct me if i am wrong. Surf, by default, it would start with evo and user can say that dont start with evo, in which case it wont start alarm. And so the option can be something similar to this. -- Sarfraaz ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: UI fixes and GNOME 2.14 timeline (was: Re: [Evolution] Error dialogs steal focus)
On Sat, 2005-12-10 at 21:59 +0100, guenther wrote:
> Cross-post on purpose.
>
> > > If Evo pops up an error ("No route to host") while a different app has
> > > the focus, the error dialog steals the focus. While this is a minor
> > > annoyance, the real problem is that after dismissing the error, the main
> > > Evo window remains focused.
> > >
> > > This even affects other Evo windows like the composer - I got a popup in
> > > the middle of typing and after clocking OK I had to Alt-Tab to find this
> > > composer window again.
> > >
> > > Is this a known bug?
> >
> > Yes it is. ALthough i really dont remember whats the bug id in
> > bugzilla.gnome.org - should look it up more thoroughly.
> >
> > We had plans to fix up a lot this (UI stuff) for 2.6 (on priority
> > basis).
>
> Just a reminder, time is running out. How are current plans and schedule
> regarding fixing UI issues on priority?
>
> 2006-01-02 00:00 UTC String/UI Change Annoucement period
> 2006-01-30 00:00 UTC Hard UI Freeze
> 2006-02-13 00:00 UTC Hard String Freeze
>
> ...bugging master
hmm :-) Im taking on these things. Ive got Johnny working on UI with me.
We should be doing a lot of fixes. We probably, can fix as much as
issues as we can. Probably, in the wiki, we can list some of must fixes
and we can go based on that as well.
>
>
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: UI fixes and GNOME 2.14 timeline (was: Re: [Evolution] Error dialogs steal focus)
On Tue, 2005-12-13 at 14:49 -0500, Lee Revell wrote: > On Tue, 2005-12-13 at 09:34 +0530, Srinivasa Ragavan wrote: > > hmm :-) Im taking on these things. Ive got Johnny working on UI with > > me. We should be doing a lot of fixes. We probably, can fix as much > > as issues as we can. Probably, in the wiki, we can list some of must > > fixes and we can go based on that as well. > > (Also cross posted on purpose) > > Please, PLEASE increase http://bugzilla.gnome.org/show_bug.cgi?id=255303 > to MUSTFIX priority > lee, i can see this working in my mail box and a workaround is applied, if i read the bug right. But it could be possible that some scenario is left. > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: UI fixes and GNOME 2.14 timeline (was: Re: [Evolution] Error dialogs steal focus)
On Tue, 2005-12-13 at 23:32 -0500, Lee Revell wrote: > On Wed, 2005-12-14 at 09:48 +0530, Srinivasa Ragavan wrote: > > On Tue, 2005-12-13 at 14:49 -0500, Lee Revell wrote: > > > On Tue, 2005-12-13 at 09:34 +0530, Srinivasa Ragavan wrote: > > > > hmm :-) Im taking on these things. Ive got Johnny working on UI with > > > > me. We should be doing a lot of fixes. We probably, can fix as much > > > > as issues as we can. Probably, in the wiki, we can list some of must > > > > fixes and we can go based on that as well. > > > > > > (Also cross posted on purpose) > > > > > > Please, PLEASE increase http://bugzilla.gnome.org/show_bug.cgi?id=255303 > > > to MUSTFIX priority > > > > > lee, i can see this working in my mail box and a workaround is applied, > > if i read the bug right. But it could be possible that some scenario is > > left. > > I know, I saw that in the code and the changelog but nevertheless it's > definitely still broken here. > > It seems to be a problem if you sort your mail by date with the newest > at the bottom. When I switch folders the scroll position keeps going > back to the top. > Ok lemme try out and see. > Lee > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: UI fixes and GNOME 2.14 timeline (was: Re: [Evolution] Error dialogs steal focus)
On Wed, 2005-12-21 at 00:55 -0500, Lee Revell wrote: > On Wed, 2005-12-14 at 17:12 +0530, Srinivasa Ragavan wrote: > > On Tue, 2005-12-13 at 23:32 -0500, Lee Revell wrote: > > > On Wed, 2005-12-14 at 09:48 +0530, Srinivasa Ragavan wrote: > > > > On Tue, 2005-12-13 at 14:49 -0500, Lee Revell wrote: > > > > > On Tue, 2005-12-13 at 09:34 +0530, Srinivasa Ragavan wrote: > > > > > > hmm :-) Im taking on these things. Ive got Johnny working on UI with > > > > > > me. We should be doing a lot of fixes. We probably, can fix as much > > > > > > as issues as we can. Probably, in the wiki, we can list some of must > > > > > > fixes and we can go based on that as well. > > > > > > > > > > (Also cross posted on purpose) > > > > > > > > > > Please, PLEASE increase > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=255303 > > > > > to MUSTFIX priority > > > > > > > > > lee, i can see this working in my mail box and a workaround is applied, > > > > if i read the bug right. But it could be possible that some scenario is > > > > left. > > > > > > I know, I saw that in the code and the changelog but nevertheless it's > > > definitely still broken here. > > > > > > It seems to be a problem if you sort your mail by date with the newest > > > at the bottom. When I switch folders the scroll position keeps going > > > back to the top. > > > > > Ok lemme try out and see. > > Were you able to verify that this is still a problem? Lee i too see it occasionally.. I'm working on it dude. > Lee > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Announce : Evolution 2.5.4, EDS 1.5.4, Evolution-exchange 2.5.4 and Gtkhtml 3.9.4
On Tue, 2006-01-03 at 12:39 -0500, Lee Revell wrote: > On Tue, 2006-01-03 at 15:29 +0530, Harish Krishnaswamy wrote: > > Hi All, > > > > The Evolution Team is pleased to announce the release of Evolution > > 2.5.4 . > > > > You can download the following : > > > > http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.5/evolution-2.5.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.5/evolution-data-server-1.5.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.5/evolution-exchange-2.5.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.9/gtkhtml-3.9.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.6.1.tar.bz2 > > > > > > Upgrade Notes : > > Evolution 2.5 is the unstable series of 2.6 development. > > > > Release Notes : > > > > Hi All, > > > > The Evolution Team is pleased to announce the release of Evolution > > 2.5.4 . > > > > You can download the following : > > > > http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.5/evolution-2.5.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.5/evolution-data-server-1.5.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.5/evolution-exchange-2.5.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.9/gtkhtml-3.9.4.tar.bz2 > > http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.6.1.tar.bz2 > > > > > > Upgrade Notes : > > Evolution 2.5 is the unstable series of 2.6 development. > > > > Release Notes : > > > > Evolution 2.5.4 2006-01-02 > > -- > > > > Bugzilla bugs fixed (see http://bugzilla.gnome.org/show_bug.cgi): > > > > Any news on when #255303 and #247373 might be fixed? I see a lot of > minor fixes and corner cases being addressed but these serious interface > bugs aren't? > Wrt bug #247373 a initial work done to distinguish user initiated/background task is done by me and partha is taking on this wrt to camel errors. So it is being looked in and not cornered :) On bug #255303, as u know this is not a regularly reproducible, im working on it. It occurs pretty rarely as you too agree to it. Im reading the code as well. You can support us by helping to find a pattern, which would be great. > Lee > > ___ > 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] Remove duplicate e-util-marshal.list in evolution/widgets/misc
Looks fine to me. -Srini On Tue, 2006-01-10 at 23:31 +0530, Harish Krishnaswamy wrote: > This change looks fine to me. Actually, it must have been just oversight > not having removed e-util-marshal.list from evolution/widgets/misc. > > Srini has been working on widgets/* more than any of us lately, though. > Thoughts, Srini ? > > Thanks, > Harish > On Tue, 2006-01-10 at 18:47 +0800, simon.zheng wrote: > > Hi all, > > > > Here is bug information. > > http://bugzilla.gnome.org/show_bug.cgi?id=323529 > > > > We found another duplicate file "e-util-marshal.list". There's two > > copies of e-util-marshal.list in and "evo/e-util" and > > "evo/widgets/misc". They're 100% identical. What's more, we noticed the > > other modules in evo/widgets, such as evo/widgets/table and > > evo/widgets/text, use the copy in evo/e-util rather than their own > > built-in copies. We think the one in evo/widgets/misc might be dropped. > > > > Attached the patch, pls review and comment. > > > > Thanks, > > -Simon > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution UI HackFest
Hi Everybody, Tomorrow Jan 12th, 2006 the Evolution Team is conducting a UI Hackfest on irc in #evolution on gimp net. We are aiming at fixing a lot of bugs that improve the user experience in performing day-to-day operations. The list of issues are listed at http://go-evolution.org/UIHackfest. You are welcome to add issues to that page and contribute patches. Happy Hacking ! -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution UI HackFest
Sorry to miss out the timezone. It will be from 0330 GMT. -Srini On Wed, 2006-01-11 at 18:44 +0100, guenther wrote: > > Tomorrow Jan 12th, 2006 the Evolution Team is conducting a UI > > Hackfest on irc in #evolution on gimp net. We are aiming at fixing a lot > > of bugs that improve the user experience in performing day-to-day > > operations. > > What timezone? > > > > The list of issues are listed at http://go-evolution.org/UIHackfest. You > > are welcome to add issues to that page and contribute patches. > > > > Happy Hacking ! > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Announce : Evolution 2.5.92, EDS 1.5.92, Evolution-exchange 2.5.92 and Gtkhtml 3.9.92
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.5.92. (2.6 Release Candidate) You can find the tarballs here : http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.5/evolution-2.5.92.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.5/evolution-data-server-1.5.92.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.5/evolution-exchange-2.5.92.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.9/gtkhtml-3.9.92.tar.bz2 What's new : Lots of bug fixes and updated translations. More information available at http://go-evolution.org/Evo2.5.92 Reporting Bugs If you have problems with 2.5.92, 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/ Thanks, Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Hard Patch Review Mode
Hi, We are entering hard code freeze on March 6th. To prepare for that, let us make sure that *all* the patches with no exceptions should be mailed to the [EMAIL PROTECTED] list. It should be committed only after a *review* by the respective maintainers. Maintainers: Just make sure that we have a respective #bug for every commit that goes into HEAD. We will probably branch after the hard code freeze for 2.7. This applies to every one, with exceptions to documentation writers and translators. The affected modules are Evolution, Evolution-data-server, GtkHTML and Evolution-Exchange. Thanks Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution, Evolution-Data-Server, GtkHTML, Evolution-Exchange branched to gnome-2-14
Hi, The gnome-2-14 branch for Evolution and Evolution-Data-Server, GtkHTML and Evolution-Exchange has been created. For specific plans on HEAD see http://go-evolution.org/Evo2.8 Thanks Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution shortcut keys review (II).
"HeadingNormal" "*Ctrl*0"bug 339093 - Control+9 ? "TextZoomReset" "*Control*0"bug 339093 Is this the only conflict? I guess both of these are in different views and wont conflict at all IMO. The user can use C+0 in both views and do the respective task. -Srini On Thu, 2006-04-20 at 01:19 +0200, Andre Klapper wrote: > hej hej, > > once again, i collected the shortcuts used within evolution (cvs head) > at > http://go-evolution.org/Shortcut_Keys_Review > > the changes done for 2.5.4 were great - seems like we have only one > existing shortcut conflict. srini, comments? > > cheers, > andre > > ___ > 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 shortcut keys review (II).
On Thu, 2006-04-20 at 11:49 +0200, Andre Klapper wrote: > hi srini, > > Am Donnerstag, den 20.04.2006, 08:43 +0530 schrieb Srinivasa Ragavan: > > "HeadingNormal" "*Ctrl*0"bug 339093 - Control+9 ? > > > > "TextZoomReset" "*Control*0"bug 339093 > > > > Is this the only conflict? I guess both of these are in different views > > and wont conflict at all IMO. The user can use C+0 in both views and do > > the respective task. > > no, they both apply to the composer, otherwise i wouldn't have marked > them as a conflict. ;-) > Oh. /evolution/ui/evolution-mail-message.xml: doesnt belong to composer and I dont remember seeing a zoom feature for composer. Am I missing something? -Srini > cheers, > andre > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Can maintainers apply three simple patches from bugzilla?
On Sun, 2006-04-23 at 02:09 +0200, Jaap Haitsma wrote: > Patches in question: > > [Bug 337258] Evolution should be the last word in Window title > http://bugzilla.gnome.org/show_bug.cgi?id=337258 > > [Bug 337257] Unread should be before total in Window title > http://bugzilla.gnome.org/show_bug.cgi?id=337257 > > [Bug 272256] Smileys in non-html mail or news messages > http://bugzilla.gnome.org/show_bug.cgi?id=272256 > Commented on bugzilla on these bugs. -Srini > Thanks > > Jaap > > > ___ > 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] How do I use e_passwords_ask_password() without segvs?
You are missing e_passwords_init (). One reason could be this.
-Srini
On Wed, 2006-04-26 at 12:27 +0200, Jules Colding wrote:
> Hi,
>
> I am trying to invoke e_passwords_ask_password() from a standalone
> application as well as from my Calendar backend. Both attempts fails
> miserably with a segv. The segv is in gtk_icon_set_render_icon() and I
> have no idea of why this happens.
>
> The standalone test code that calls e_passwords_ask_password() is rather
> trivial. Essentially linking all the right libraries, including all the
> right headers and just doing:
>
> int
> main (int argc, char *argv[])
> {
> gboolean remember = FALSE;
> char *password = NULL;
>
> g_type_init();
> g_thread_init(NULL);
>
> password = e_passwords_ask_password("Enter password",
> "Brutus",
> "profile",
> "prompt",
> E_PASSWORDS_REMEMBER_NEVER,
> &remember,
> NULL);
> return EXIT_SUCCESS;
> }
>
> I would really appreciate any help in with this and have appended the
> (lengthly) valgrind output below.
>
> Thanks a lot in advance,
> jules
>
>
> ### valgrind output
> ==11895== Memcheck, a memory error detector.
> ==11895== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
> ==11895== Using LibVEX rev 1471, a library for dynamic binary translation.
> ==11895== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==11895== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
> ==11895== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
> ==11895== For more details, rerun with: -v
> ==11895==
>
> (process:11895): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion
> `GDK_IS_SCREEN (screen)' failed
>
> (process:11895): GLib-GObject-CRITICAL **: g_object_get: assertion
> `G_IS_OBJECT (object)' failed
> ==11895== Conditional jump or move depends on uninitialised value(s)
> ==11895==at 0xCDAFF9: g_param_value_validate (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD9B8A: g_object_set_valist (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD9FA5: g_object_set (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0x7295740: (within /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0x7295C97: (within /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0xCD7E59: g_object_newv (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD89D8: g_object_new_valist (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD8ADF: g_object_new (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0x729560B: gtk_button_new_from_stock (in
> /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0x72E120E: gtk_dialog_add_button (in
> /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0x7371F1C: (within /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0xCDA1DB: (within /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==
> ==11895== Conditional jump or move depends on uninitialised value(s)
> ==11895==at 0xCF7390: (within /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCF4CB4: g_value_transform (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCF8F11: g_strdup_value_contents (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD9DE6: g_object_set_valist (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD9FA5: g_object_set (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0x7295740: (within /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0x7295C97: (within /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0xCD7E59: g_object_newv (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD89D8: g_object_new_valist (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0xCD8ADF: g_object_new (in
> /usr/lib/libgobject-2.0.so.0.1000.2)
> ==11895==by 0x729560B: gtk_button_new_from_stock (in
> /usr/lib/libgtk-x11-2.0.so.0.800.17)
> ==11895==by 0x72E120E: gtk_dialog_add_button (in
> /usr/lib/libgtk-x11-2.0.so.0.800.17)
>
> (process:11895): GLib-GObject-WARNING **: value "TRUE" of type `gboolean' is
> invalid or out of range for property `visible' of type `gboolean'
>
> (process:11895): Gtk-CRITICAL **: gtk_settings_get_for_screen: assertion
> `GDK_IS_SCREEN (screen)' failed
>
> (process:11895): GLib-GObject-CRITICAL **: g_object_get: assertion
> `G_IS_OBJECT (object)' failed
>
> (process:11895): GLib-GObject-WARNING **: value "TRUE" of type `gboolean' is
> invalid or out of range for property `visible' of type `gboolean'
>
> (process:11895): GLib-GObject-CRITICAL **: g_object_get: assertion
> `G_IS_OBJECT (object)' failed
> ==11895==
> ==11895== Conditional jump or move depends on uninitia
Re: [Evolution-hackers] [PATCH 1/3] Provide declaration for get_font_options()
Pavel,
Please commit this.
Thanks
Srini.
On Mon, 2006-08-14 at 19:58 -0400, Pavel Roskin wrote:
> From: Pavel Roskin <[EMAIL PROTECTED]>
>
> gtk/gtk.h needs to be included to make sure that cairo_font_options_t is
> defined. Without this patch, callers of get_font_options() get the
> lower 32 bit of the pointer, which causes breakage on 64-bit systems.
> ---
>
> e-util/e-util.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/e-util/e-util.h b/e-util/e-util.h
> index 0346a9f..d885f9f 100644
> --- a/e-util/e-util.h
> +++ b/e-util/e-util.h
> @@ -28,6 +28,7 @@ #include
> #include
> #include
> #include
> +#include
>
> #ifdef __cplusplus
> extern "C" {
> @@ -214,6 +215,7 @@ gchar*e_ascii_dtostr
> Less than 0 for the int means copy the whole string. */
> gchar*e_strdup_append_strings
> (gchar *first_string,
>
> ...);
> +cairo_font_options_t *get_font_options();
>
> #ifdef __cplusplus
> }
> ___
> 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] [PATCH 3/3] Add some missing includes
Pavel, I guess it is good to follow what is already there. Please commit. Thanks Srini. On Mon, 2006-08-14 at 19:58 -0400, Pavel Roskin wrote: > From: Pavel Roskin <[EMAIL PROTECTED]> > > > --- > > widgets/misc/e-icon-entry.c |2 ++ > widgets/table/e-cell-text.c |1 + > widgets/table/e-table-utils.c |1 + > 3 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/widgets/misc/e-icon-entry.c b/widgets/misc/e-icon-entry.c > index 8b8e5af..28779dc 100644 > --- a/widgets/misc/e-icon-entry.c > +++ b/widgets/misc/e-icon-entry.c > @@ -39,6 +39,8 @@ #include "e-icon-entry.h" > #include > #include > #include > +#include > +#include > > #define E_ICON_ENTRY_GET_PRIVATE(object)(G_TYPE_INSTANCE_GET_PRIVATE > ((object), E_TYPE_ICON_ENTRY, EIconEntryPrivate)) > > diff --git a/widgets/table/e-cell-text.c b/widgets/table/e-cell-text.c > index fee7d04..0de2375 100644 > --- a/widgets/table/e-cell-text.c > +++ b/widgets/table/e-cell-text.c > @@ -45,6 +45,7 @@ #include > #include > #include > #include > +#include > > #include "a11y/e-table/gal-a11y-e-cell-registry.h" > #include "a11y/e-table/gal-a11y-e-cell-text.h" > diff --git a/widgets/table/e-table-utils.c b/widgets/table/e-table-utils.c > index 178842c..ac149e1 100644 > --- a/widgets/table/e-table-utils.c > +++ b/widgets/table/e-table-utils.c > @@ -24,6 +24,7 @@ > #include > > #include /* This file uses dgettext() but no _() */ > +#include > > #include "e-util/e-util.h" > #include "misc/e-unicode.h" > ___ > 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] CamelStreamMem ==> CamelStream ?
On Thu, 2006-11-16 at 15:10 +0100, Jules Colding wrote: > Hi, > > I'm looking for an easy way to transfer the content of a CamelStreamMem > to a CamelStream without having a duplicate of the content around. Does > anyone know a non-hackish(*) way to do that? You can use CamelStreamMem as CamelStream directly. IIRC while reading some code in em-format-html-display.c, I saw the CamelMemStream being accessed as stream->buffer->data where as buffer is a GByteArray. -Srini. > > What I want to accomplish is to read a structure from memory into a > CamelStreamMem and then store it in a CamelDataCache. > > Maybe there is a better way to do this? > > Thanks, > jules > > > (*) Without accessing the private buffer member. > > ___ > 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] RFC: Evolution's library requirements
On Wed, 2006-12-06 at 00:51 +0530, Harish Krishnaswamy wrote: > Hi fellow hackers, > > With reference to Bug 380534 on clarifying Evolution's library > requirements, I am putting down my thoughts and recommendations here and > will be proposing this in the weekly evolution meeting (#evolution-meet > on irc.gimp.org at 1000 UTC 6 Dec 2006) tomorrow. Comments/questions > welcome, as always. > > I see two aspects of the problem described in the bug that merit two > separate approaches : > > a. Inbound Dependencies - The libraries that Evolution/EDS/Evolution > Exchange depend on. > b. Outbound Dependencies - Dependencies that EDS libraries provides to > other applications that are based on or integrated with Evolution/EDS. > > On (a) Inbound Dependencies, > > I suggest that on upstream CVS, Evolution should depend on the most > recent stable versions of the libraries available in the corresponding > GNOME release (Evolution 2.9.x/2.8.x on GNOME 2.16, 2.6.x on GNOME > 2.14). This is similar but not exactly the same as what Matthew has > outlined in Bug 380534. I agree that the configure scripts need to > hard-enforce these dependencies while building the packages. > > I feel it is important that we move away from > i) the use of deprecated APIs from various GNOME libraries to the > improved, maintained versions. > ii) Evolution specific widgets/thread/mutex/data structures > implementation that are now available in generic GNOME libraries. This > is possible now in some cases (EList->GList, EThread->GThread, > EMutex->GMutex?) but not all (ETable, ETree). > > This ensures we take advantage of the newer capabilities available and > make it easier for contributors to continue adding value to our project. > > However, it is also true that a very large number of our users > (enterprise, organizations, ISVs) still live on older GNOME Desktop > environments (Gtk <= 2.6), willing to upgrade specific applications > (Evo) but not their entire Desktop every six months. I think this would > be the case in future too that the 'majority' of the installed base > stays a step or two behind the Bleeding-Edge/State-Of-The-Art Latest > releases. > > If-defs and conditional compilations with significant addition to the > maintenance complexity are a necessity to support such users who need to > move to newer versions without overhauling their desktop. It is fair > IMHO, however, for individual distributions to handle them according to > their needs, rather than the upstream maintaining a super-set of > everybody's constraints. > I agree with this. The backward compatibility with older GNOME shouldn't be maintained in HEAD IMHO. This will also help to keep the code pretty clean. -Srini > I wish to propose an exception to the above if and only if when an > inbound dependency is likely to cause a change to an outbound dependency > as discussed in (b). > > > On (b) Outbound dependencies, > and this is specially relevant to bugs like 373117, where we would like > to preserve the binary compatibility of outbound libraries (libebook and > libecal, in particular, which are the heavily used ones and as well as > various Camel/Calendar/Addressbook providers built on EDS) and take care > that any changes do not trigger massive upgrade overheads for those who > consume our libraries. Evolution has learnt this the hard way, erred on > some and handled them with additional code overheads in other cases. > > Here, I would recommend that we extend the APIs rather than > modify/delete them and mark the deprecated functions (to be discarded > after a specified and sufficient timeline) so that they do not get used > in newer code. These libraries need to support older environments (and > possibly deprecated library calls) in a broader sense than in case (a). > In these cases, some conditional compilation and #ifdef hacks will have > to be supported on the upstream as well. I wish I could specify hard > numbers on minimum dependencies for various libraries here. ( Is > 'Libraries corresponding to GNOME 2.14' a good one ?) but I do not have > the answers yet. If you have a POV that you feel must be considered, > please do let me know or join us in the meeting tomorrow. > (There has also been a separate discussion on the need to get > Evolution's Camel library versioned and promise a compatible interface > for foreseeable future and Varadhan is already working on this with > other mail hackers). > > > I also feel the library dependencies are best conveyed by the build > tools and our decisions should be reflected in and enforced by our > pkg-config and configure scripts. (remember the recurring NSS/NSPR , > LDAP/NTLM issues ?) > The Answer : Patch and Testing love [hint...hint ;-)] > > > Thanks, > Harish > > > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___
Re: [Evolution-hackers] Visual indication of online/offline?
Hey Jules, I have some plans on the intrusive error dialogs stuff. I dont think I can work on the current release time frame. May be post 2.10 is what I'm looking at. Basically cancel-able should be tasks, with a 'x' button in the status bar. If any errors occur, a '!' next to the status bar text and a visual cue to indicate error, which user can click and see the respective errors. The user can choose to see or cancel all tasks/errors and no more intrusive popups. All background/foreground tasks will have a visible entry in the status bar. This is an initial idea I had, but Im sure, there could be lots of improvements to it. The idea of having a visual indication at the store level is good. This idea will also add more value if we can have store level online/offline state. -Srini. On Wed, 2006-12-06 at 12:06 +0100, Jules Colding wrote: > Hi, > > Is there any way to signal a visual indication that a specific > CamelStore is offline? I'm thinking that making the account blink in > bright red or maybe just a little store specific offline icon next to > the account in the side bar would be much better than a CamelException. > > An exception is presented as an error to the user in a popup window. I > would rather like to gently show a warning to the user. A popup is > really disturbing... > > > Thanks, > jules > > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Visual indication of online/offline?
Hey Andre, On Wed, 2006-12-06 at 23:46 +0100, Andre Klapper wrote: > hej srini, > > Am Mittwoch, den 06.12.2006, 17:20 + schrieb Srinivasa Ragavan: > > I have some plans on the intrusive error dialogs stuff. > > any mockups or code to test attached to > http://bugzilla.gnome.org/show_bug.cgi?id=247373 would be gladly > welcome, once it exists. :-) > Sure. As I said, I haven't started anything on this. I would be working on this mostly from Jan. Would add some UI mocks to the bug at that time. Thanks Srini. > cheers, > andre > > ___ > 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] Reorganize Evolution's preferences dialog
Hi Matthew I think it is a pretty good idea :-). The two main reason are - Width is controlled by the number of tabs in Mail Preferences - Height is controlled by the General tab in Mail Preferences On Wed, 2006-12-06 at 14:12 -0500, Matthew Barnes wrote: > I'm running Evolution 2.9.3 with a 1024x768 screen resolution and > Evolution's Preferences dialog barely fits on my screen. I had an idea > on how we might shrink this down a bit by reorganizing some tabs. I'm > not proposing a complete overhaul of the preferences at this time, just > some minor changes that I think can be accomplished before Evolution > 2.10 ships. > > The General tab of the Mail Preferences section currently defines the > size of the Preferences dialog, so the goal is to reduce the contents of > this tab. > > My suggestions are: > > 1) There is both a "Calendar and Tasks" section and a "Mail Preferences" >section with a "Calendar and Tasks" tab. Eliminate the tab in the >"Mail Preferences" section as follows: > > a) Move the "Delete message after acting" option to the General > tab in the "Calendar and Tasks" section. > b) Move the conflicts options to a new "Conflicts" tab in the > "Calendar and Tasks" section. > I think if you add "Conflicts" tab to calendar prefs, the number of tabs would increase and it may start controlling the width. For that we can also remove the "Free/Busy" tab in "Calendar and Tasks" and add merge it with calendar publishing by renaming the tab as "Publishing". Both these tab mean free/busy and calendar publishing. > 2) Add a new section called "Contacts" and make the "Autocompletion" >section a tab within the "Contacts" section. > This is pretty cool. > 3) Move the "Automatic Contacts" tab in the "Mail Preferences" section >to the new "Contacts" section. Maybe rename the tab to "General"? > > 4) With the number of tabs in the "Mail Preferences" section now >diminished, split the mail notification options in the "General" tab >to a new "Notification" tab. Cool. > > Voilà, shrinkage! > > Comments? Other ideas? Thanks for the initiative :). -Srini. > > Matthew Barnes > > ___ > 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] Bug #127529
Hi Matthew, This is not yet completed rather not started. Im not sure, whether you can do this as EPlugin. But would be great if you can make that hook (if it is not there)and do that as EPlugin. Thanks Srini. On Wed, 2006-12-13 at 21:21 -0600, Matthew Martin wrote: > I was thinking about fixing this: > http://bugzilla.gnome.org/show_bug.cgi?id=127529 (Bug #127529). I wanted > to make sure this is still needed before I started working on it. If > this is still needed I should use EPlugin to make it right? > > Thanks, > Matthew > > ___ > 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] Dead GtkHtml code?
Hi Matthew, On Thu, 2007-01-04 at 21:05 -0500, Matthew Barnes wrote: > Looking for some historical insight here. > > There's a directory in GtkHtml's Subversion repository called "capplet". > This directory is not included in GtkHtml release tarballs, and the > latest capplet/ChangeLog entry is dated 2004-07-22. > > Is this code officially dead? >From first read, this code seems to be dead. Its not even under compilation path. > > The only mention of it's demise that I've found is a brief ChangeLog > entry in the top-level directory: > > 2003-01-13 Rodney Dawes <[EMAIL PROTECTED]> > > * configure.in: Remove the capplet stuff > > I ask because I'm trying to clean up parts of GtkHtml's code (fixing > compiler warnings, moving off deprecated GTK+ widgets, etc.) and I'd > like to know whether the capplet stuff is worth bothering with. Don't bother it IMO. > > Matthew Barnes > > > p.s. If it _is_ dead, should it not be removed from source control? On a closer look, it seems to have some old code for shortcut configuration. It may be of our interest some time down the line. I feel that it should be OK to have it under the source control for some more time. Thanks Srini. > > ___ > Evolution-hackers mailing list > Evolution-hackers@gnome.org > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Why is GnomePrintContext still in GtkHtml?
Matthew,
It is an exposed interface, that is lying around after the GtkPrint
migration. It should be removed in the next few updates.
-Srini.
On Mon, 2007-01-22 at 19:41 -0500, Matthew Barnes wrote:
> So I'm a little bit confused about this recent GtkPrint migration. I'm
> seeing things in the GtkHtml code like this:
>
> void html_engine_print (HTMLEngine *e,
> GtkPrintContext*print_context);
>
> ...
>
> void
> gtk_html_print (GtkHTML *html,
> GnomePrintContext *print_context)
> {
> g_return_if_fail (html != NULL);
> g_return_if_fail (GTK_IS_HTML (html));
>
> html_engine_print (html->engine, print_context);
> }
>
> How does print_context magically change from a GnomePrintContext to a
> GtkPrintContext? Is this an oversight or are we doing something dirty?
>
> Matthew Barnes
>
> ___
> 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.9.91 and Evolution-Data-Server 1.9.91 released (with GtkHTML 3.13.91 and Evolution-Exchange-2.9.91)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.91 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.91.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.91.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.91.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.91.tar.bz2 Upgrade Notes : Evolution 2.9.x is the unstable series of 2.10 development. What is New ? = Evolution: == Updated Translations: Djihed Afifi (ar) Theppitak Karoonboonyanan (th) Stéphane Raimbault, Robert-André Mauchin and Stéphane Raimbault (fr) Duarte Loreto (pt) Hendrik Richter (de) David Lodge (eb_GB) Pema Geyleg (dz) Changwoo Ryu (ko) Daniel Nylander (sv) Andre Klapper (de) Chao-Hsiung Liao (zh_HK) Chao-Hsiung Liao (Zh_TW) Ivar Smolin (et) Gabor Kelemen (hu) Ilkka Tuohela (fi) Kjartan Maraas (nb) Contributors: Nickolay V. Shmyrev, Wang Xin, Ebby Wiselyn, Duarte Loreto, Matthew Barnes, Ushveen Kaur, William Jon McCann, Andre Klapper, Raghavendran, Srinivasa Ragavan, Sankar P, Kjartan Maraas, Wang Xin, Matthias Clasen Evolution-data-server: = Updated Translations: Duarte Loreto (pt) Pema Geyleg (dz) Djihed Afifi (ar) Changwoo Ryu (ko) Daniel Nylander (sv) Raphael Higino (pt_BR) Hendrik Richter (de) Priit Laes and Ivar Smolin (et) Contributors: Sankar P Harish Krishnaswamy Kjartan Maraas Priit Laes Patrick Ohly Ross Burton Trond Myklebust Evolution-exchange: == Updated Translations: Xavier Conde Rueda (ca) Duarte Loreto (pt) Djihed Afifi (ar) Stéphane Raimbault (fr) Raphael Higino (pt_BR) Daniel Nylander (sv) Priit Laes (et) GtkHTML: === Major Changes - GtkPrint Migration improvements from Ebby Wisely - Massive Code Cleanup from Matthew Barnes Bug Fixes: Kjartan Maraas Matthew Barnes Chenthill Palanisamy Updated Translations: Jonathan Ernst and Claude Paroz (fr) David Lodge (en_GB) Djihed Afifi (ar) Daniel Nylander (sv) Theppitak Karoonboonyanan (th) Kjartan Maraas (nb) Priit Laes (et) Reporting Bugs If you have problems with 2.9.91, 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. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also 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/ Thanks, Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
On Thu, 2007-02-22 at 00:38 -0700, Sankar P wrote: > If all you need is just a non-deleting draft, you can use "Edit as new > message". I have felt that this shouldn't be restricted to Sent-items > alone as we allow configurable sent-folders. IIRC, there is a bug for > this as well. > > Srini: Shall we make this available on all folders ? Im not for this feature against templates. I feel that templates should be treated seperately. But I feel that this menu item should be enabled for all folder, unless it breaks mail abstraction if any. -Srini > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Why is GnomePrintContext still in GtkHtml?
Hi Frederic, We did update the GtkHTML versions under the assumptions of API extensions in 3.13.90. In 3.13.91 we have broken API/ABI and removed the obsolete APIs but we havent bumped the versions accordingly. We will be doing that in RC Monday. Thanks for pointing it out to us :) -Srini. On Thu, 2007-02-22 at 14:40 +0100, Frederic Crozat wrote: > Le mardi 23 janvier 2007 à 08:43 +0530, Srinivasa Ragavan a écrit : > > Matthew, > > > > It is an exposed interface, that is lying around after the GtkPrint > > migration. It should be removed in the next few updates. > > Well, this change is breaking API and ABI. It would be nice to change > gtkhtml major, since it isn't ABI compatible with previous version of > gtkhtml. > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Patching Evolution to retrieve a list of emails and calendar events through DBUS
Hey Jo, On Fri, 2007-02-23 at 13:41 +0100, Jo Vermeulen wrote: > Hello, > > I was wondering how hard it would be to patch Evolution (or write a > plugin) to be able to retrieve a list of emails and calendar events > through DBUS? Shouldn't be that hard :). I think calendar has to be interfaced via EDS than Evolution. This way even contacts can also take the advantage. > > Is is possible to give me a few pointers on how I could do this? I have > no experience with Evolution whatsoever. What sort of pointers you need. Evolution has quite a few hooks where you can plug code. We can add more hooks if required. But do you have a plan of what you are trying to achieve through DBUS interface. I think once you can close on that, we can easily expose hooks for the evolution-dbus-plugin. For some hints to start with, you can looks at the new-mail-notification plugin in Evolution which uses DBUS. > > In my opinion, exposing a lot of Evolution's functionality through DBUS > would allow for better integration in the desktop. Sure. This sounds exciting to me. Thanks Srini. > > Cheers, > > ___ > 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] Patching Evolution to retrieve a list of emails and calendar events through DBUS
On Fri, 2007-02-23 at 16:12 +0100, Jo Vermeulen wrote: > On Fri, 2007-02-23 at 18:28 +0530, Srinivasa Ragavan wrote: > > Hey Jo, > > > > On Fri, 2007-02-23 at 13:41 +0100, Jo Vermeulen wrote: > > > Hello, > > > > > > I was wondering how hard it would be to patch Evolution (or write a > > > plugin) to be able to retrieve a list of emails and calendar events > > > through DBUS? > > Shouldn't be that hard :). I think calendar has to be interfaced via EDS > > than Evolution. This way even contacts can also take the advantage. > > I am looking into something that won't take me a week or so to > implement :-) > > > > Is is possible to give me a few pointers on how I could do this? I have > > > no experience with Evolution whatsoever. > > > > What sort of pointers you need. Evolution has quite a few hooks where > > you can plug code. We can add more hooks if required. But do you have a > > plan of what you are trying to achieve through DBUS interface. > > What we want to do is create an application that enables you to link > your emails, contacts, calendar items and the like. For now, we could > use DBUS to interface with Gaim and Tomboy, but Evolution is a bit more > troublesome. > > In fact we would like to get a list of emails that have the label > "Todo", and a set of calendar events for a certain date. Wow. Sounds interesting :) > > > I think > > once you can close on that, we can easily expose hooks for the > > evolution-dbus-plugin. For some hints to start with, you can looks at > > the new-mail-notification plugin in Evolution which uses DBUS. > > I had a look at that indeed, but I'm not sure how these plugins can be > loaded dynamically. Is it possible for me to develop a plugin, load it > into Evolution and try it out? This would enable rapid prototyping which > would speed up development ;-) You can google at tnef plugin which Notzed wrote long back. It was written/compiled separately and loaded dynamically into Evolution. So it is possible to load dynamically. > > > > In my opinion, exposing a lot of Evolution's functionality through DBUS > > > would allow for better integration in the desktop. > > > > Sure. This sounds exciting to me. > > Indeed it is. Unfortunately I don't have a lot of time to spare, > although I can spend a few days working on this. I doubt. It may take more than few days. I expect atleast 1-2 weeks. But you can scope out to just Email and Calendar and get a volunteer for the rest of the components. Anyways. All the very best !!! -Srini. > > Thanks for your quick reply! > > Best regards, > > ___ > 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] Patching Evolution to retrieve alist ofemails and calendar events through DBUS
On Fri, 2007-02-23 at 11:08 -0700, Veerapuram Varadhan wrote: > On Fri, 2007-02-23 at 17:15 +0100, Jo Vermeulen wrote: > > On Fri, 2007-02-23 at 08:58 -0700, Veerapuram Varadhan wrote: > > > On Fri, 2007-02-23 at 21:06 +0530, Srinivasa Ragavan wrote: > > > > On Fri, 2007-02-23 at 16:12 +0100, Jo Vermeulen wrote: > > > > > On Fri, 2007-02-23 at 18:28 +0530, Srinivasa Ragavan wrote: > > > > > > Hey Jo, > > > > > > > > > > > > On Fri, 2007-02-23 at 13:41 +0100, Jo Vermeulen wrote: > > > > > > > Hello, > > > > > > > > > > > > > > I was wondering how hard it would be to patch Evolution (or write > > > > > > > a > > > > > > > plugin) to be able to retrieve a list of emails and calendar > > > > > > > events > > > > > > > through DBUS? > > > > > > Shouldn't be that hard :). I think calendar has to be interfaced > > > > > > via EDS > > > > > > than Evolution. This way even contacts can also take the advantage. > > > > > > > > > > I am looking into something that won't take me a week or so to > > > > > implement :-) > > > > > > > > > > > > Is is possible to give me a few pointers on how I could do this? > > > > > > > I have > > > > > > > no experience with Evolution whatsoever. > > > > > > > > > > > > What sort of pointers you need. Evolution has quite a few hooks > > > > > > where > > > > > > you can plug code. We can add more hooks if required. But do you > > > > > > have a > > > > > > plan of what you are trying to achieve through DBUS interface. > > > > > > > > > > What we want to do is create an application that enables you to link > > > > > your emails, contacts, calendar items and the like. For now, we could > > > > > use DBUS to interface with Gaim and Tomboy, but Evolution is a bit > > > > > more > > > > > troublesome. > > > > > > > > > > In fact we would like to get a list of emails that have the label > > > > > "Todo", and a set of calendar events for a certain date. > > > > Wow. Sounds interesting :) > > > Calendar/Contacts can still be queried using Evolution#, which is > > > currently used by Beagle. However, querying mails is not yet supported > > > in Evolution#. > > > > Indeed, that would be another possibility. However, Evolution# has no > > documentation. If anyone could help me get started with Evolution# that > > would be great! > > > If you check-out evolution-sharp, you would see evolution/TestCal.cs and > evolution/TestBook.cs - these files help you to understand how to use > the basic APIs. > > Alternatively, you can checkout: > http://svn.gnome.org/viewcvs/beagle/trunk/beagle/beagled/EvolutionDataServerQueryable/CalContainer.cs?revision=3170&view=markup > - for Calendar APIs > and > http://svn.gnome.org/viewcvs/beagle/trunk/beagle/beagled/EvolutionDataServerQueryable/BookContainer.cs?revision=3223&view=markup > - for Contacts APIs > > > > > > > I think > > > > > > once you can close on that, we can easily expose hooks for the > > > > > > evolution-dbus-plugin. For some hints to start with, you can looks > > > > > > at > > > > > > the new-mail-notification plugin in Evolution which uses DBUS. > > > > > > > > > > I had a look at that indeed, but I'm not sure how these plugins can be > > > > > loaded dynamically. Is it possible for me to develop a plugin, load it > > > > > into Evolution and try it out? This would enable rapid prototyping > > > > > which > > > > > would speed up development ;-) > > > > You can google at tnef plugin which Notzed wrote long back. It was > > > > written/compiled separately and loaded dynamically into Evolution. So it > > > > is possible to load dynamically. > > > > > > > Even if a plugin is written, you cannot get the notification unless you > > > run Evolution - so, whatever your application is will have a > > > hard-dependency on a running version of evolution. Just a thought. > > > > Yes indeed, but isn't this a problem for Evolution# as well? Doesn't it > > also need a running instance of Evolution? > Evolution# doesn't need a running instance of Evolution - since, it is > confined to only Calendar and Contacts. We had a mail-remote-glue > written in Evolution# that would talk to evolution using > bonobo-interface, but, we pulled it back. Alternatively, you can have a look at the mail-remote plugin under Evolution, which reads <_description>A plugin which implements a CORBA interface for accessing mail data remotely. -Srini. > > Cheers, > > V. Varadhan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.9.92 and Evolution-Data-Server 1.9.92 released (with GtkHTML 3.13.92 and Evolution-Exchange-2.9.92)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.92 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.92.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.92.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.92.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.92.tar.bz2 Upgrade Notes : Evolution 2.9.x is the unstable series of 2.10 development. What is New ? = Evolution: == Major Updates: Documentation updates from PC Radhika. Updated Translations: Luca Ferretti (it) Ivar Smolin (et) Changwoo Ryu (ko) Gabor Kelemen (hu) Kjartan Maraas (nb) Gintautas Miliauskas (lt) Jordi Mas (ca) Daniel Nylander (sv) Leonid Kanter (ru) Funda Wang (zh_CN) Artur Flinta (pl) Leonardo Ferreira Fontenelle, Washington Lins (pt_BR) Stéphane Raimbault (fr) Nguyễn Thái Ngọc Duy (vi) Alexander Shopov (bg) David Lodge (en_GB) Djihed Afifi (ar) Leonid Kanter (ru) Duarte Loreto (pt) Ilkka Tuohela (fi) Theppitak Karoonboonyanan (th) Contributors: Matthew Barnes, Raghavendran R, Srinivasa Ragavan, Ebby Wiselyn, Harish Krishnaswamy, Chenthill Palanisamy, Sankar P Evolution-data-server: = Updated Translations: Gabor Kelemen (hu) Luca Ferretti (it) Artur Flinta (pl) Priit Laes (et) Contributors: Gilles Dartiguelongue Matthew Barnes Evolution-exchange: == Updated Translations: Changwoo Ryu (ko) Gabor Kelemen (hu) Alexander Shopov (bg) Peter Bach (da) Artur Flinta (pl) Kjartan Maraas (nb) Hendrik Brandt (de) Ilkka Tuohela (fi) Contributors: Kjartan Maraas, Varadhan, Nathan Owens, Harish GtkHTML: === Bug Fixes: Harish Krishnaswamy Matthew Barnes Gilles Dartiguelongue Updated Translations: Luca Ferretti (it) Gabor Kelemen (hu) Changwoo Ryu (ko) Nguyễn Thái Ngọc Duy (vi) Alexander Shopov (bg) Leonardo Ferreira Fontenelle (pt_BR) Artur Flinta (pl) Maxim Dziumanenko (uk) Hendrik Brandt (de) Duarte Loreto (pt) Ilkka Tuohela (fi) Kjartan Maraas (nb) Priit Laes (et) Reporting Bugs If you have problems with 2.9.92, 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. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also 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/ Thanks, Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 2.9.92 and Evolution-Data-Server 1.9.92 released (with GtkHTML 3.13.92 and Evolution-Exchange-2.9.92)
Hi William, On Tue, 2007-02-27 at 14:27 +, William John Murray wrote: > On Tue, 2007-02-27 at 13:45 +0530, Srinivasa Ragavan wrote: > > Hi All, > > > > The Evolution Team is pleased to announce the release of Evolution > > 2.9.92 > > > I am still unable to configure this of a x86_64 FC6 machine. > The problem is the openldap. FC6 has a > special /usr/lib/evolution-ldap/lib > area for ntlm-enabled ldap, just for evolution. But on 64 bit I get a > mess. The area is now: IIRC Evolution use to need NTLM enabled openldap. It used to be referred as evolution-ldap. I think the latest openldap has NTLM support built in and doesn't need the patched one anymore. Also, Im not very sure how this applies to FC. -Srini >/usr/lib64/evolution-ldap/lib64 > but configure looks for /usr/lib64/evolution-ldap/lib > OK, I can soft-link lib64 and lib. But I still get, from > PKG_CONFIG_PATH=/opt/evo-2.9.92/lib/pkgconfig ./configure > --prefix=/opt/evo-2.9.92 --with-openldap=/usr/lib64/evolution-openldap > --with-krb5=/usr --with-static-ldap --enable-gnome-keyring=yes > > configure:28238: checking for ldap_open in -lldap > configure:28268: gcc -o conftest -g -O2 conftest.c -lldap > -L/usr/lib64/evolution-openldap/lib > /usr/lib64/evolution-openldap/lib/liblber.a -lnsl >&5 > /usr/lib64/evolution-openldap/lib/libldap.a(os-ip.o): In function > `ldap_connect_to_host': > (.text+0xb2a): warning: `sys_errlist' is deprecated; use `strerror' or > `strerror_r' instead > /usr/lib64/evolution-openldap/lib/libldap.a(os-ip.o): In function > `ldap_connect_to_host': > (.text+0xb1b): warning: `sys_nerr' is deprecated; use `strerror' or > `strerror_r' instead > /usr/lib64/evolution-openldap/lib/libldap.a(tls.o): In function > `ldap_pvt_tls_get_my_dn': > (.text+0xcc): undefined reference to `SSL_get_certificate' > /usr/lib64/evolution-openldap/lib/libldap.a(tls.o): In function > `ldap_pvt_tls_get_my_dn': > (.text+0xd9): undefined reference to `X509_get_subject_name' > /usr/lib64/evolution-openldap/lib/libldap.a(tls.o): In function > `ldap_pvt_tls_get_strength': > (.text+0x125): undefined reference to `SSL_get_current_cipher' > /usr/lib64/evolution-openldap/lib/libldap.a(tls.o): In function > `sb_tls_close': > > and a lot more subsequent errors. >Can anyone suggest what I should do? > Thanks, >Bill ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory management in mail message formatting
Riccardo, IIRC while solving some inline image crashes, I came across a similiar issue. For that I added a free function to the puri, which gets called when the puri is freed. You can see em-format.h:119 You can use this to achieve what you need. -Srini On Wed, 2007-02-28 at 19:54 +0100, Riccardo Lancellotti wrote: > Hi. > I am working on the next release of the patch to show the contact photo > of the "from:" address in the mail messages (bug #360184). > > I have some doubt about how memory is managed during mail message > formatting. > If I am not wrong, the formatting of single elements such as icons is > asynchronous and is managed through em_format_add_puri(), where > em_format_add_puri requests a CamelMimePart object as a parameter > > Now the critical question: I create a CamelMimePart object from a memory > buffer obtained from e-d-s interaction (the contact photo from the > addressbook). The EContactPhoto is not a GObject, but just a struct that > I must free on my own (no g_objet_unref magic can help me). > > The problem is that I have not a clear idea on *when* g_free must be > called. > Freeing memory in the main thread is not a good idea and leads to random > crashes (especially when reading mailing lists in digest mode -- tried > on the currently available patch). > *Not* freeing memory seems to be even worse because it looks like a > memory leak. > > Is there some document that helps me understand the inner details of > mail message formatting? Do you have any advice? > > ___ > 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] bugs.
Andre, On Thu, 2007-03-01 at 04:09 +0100, Andre Klapper wrote: > > can evolution developers please run their desktops with accessibility > enabled, to also run into this issue 5 times a day, like i do? > srini, can the patch please go in for 2.10? As, I have commented on the bug itself. It just avoids the crash and can go in. I have updated bugzilla also now to commit_now. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Bug in main_system_beep?
On Fri, 2007-03-30 at 07:48 +0100, Karl Relton wrote:
> Srini
>
> Welcome to your new role.
Thanks you.
> I posted this on evolution-patches a couple of
> weeks back, but don't think anyone has got round to it yet ...
>
>
> Whilst looking at the code for other things, I think I have spotted a
> bug in main_system_beep() in mail-session.c.
You are absolutely right. It is a bug and the patch fixes it right. Just
for tracking, file a bug and attach the patch to bugzilla (Pass us the
bug id). It has to go for STABLE and trunk branches.
-Srini.
>
> Comparing the beep function with play_sound function:
>
> session_play_sound() and main_play_sound() do a
> camel_object_ref(session) and a camel_object_unref(session) between
> them.
>
> However, session_system_beep() and main_system_beep() does the
> camel_object_ref(session) but without the corresponding unref.
>
> I assume thats wrong - the patch below fixes that by putting in the
> unref.
>
> Karl
>
> --- mail-session.c.old 2007-03-02 11:31:23.0 +
> +++ mail-session.c 2007-03-02 11:29:42.0 +
> @@ -441,6 +441,7 @@ static void
> main_system_beep (CamelFilterDriver *driver, gpointer user_data)
> {
> gdk_beep ();
> + camel_object_unref (session);
> }
>
> static void
>
>
> ___
> 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] Proposed fix for bug 311512
On Fri, 2007-03-30 at 07:51 +0100, Karl Relton wrote:
> Srini
>
> Welcome to your new role (again!).
>
> Last week I posted two patches (one for eds, one for evo) on evo bugzill
> that I believe fix bug 311512.
> --- camel-folder.h.1102007-03-20 16:57:40.0 +
> +++ camel-folder.h2007-03-20 16:50:34.0 +
> @@ -195,6 +195,7 @@ typedef struct {
> void (*freeze)(CamelFolder *folder);
> void (*thaw) (CamelFolder *folder);
> gboolean (*is_frozen) (CamelFolder *folder);
> + int (*get_filter_thread) (CamelFolder *folder);
> } CamelFolderClass;
On first look, I noticed that your patch has introduced an ABI break in
CamelFolderClass.
I'm sure that the mailer hackers would have a more closer look at it.
Thanks for your friendly poke :-)
-Srini.
> f
> Could you take a look - any comments are welcome!
>
> Regards
> Karl
>
> ___
> 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 Maintainership
On Thu, 2007-03-29 at 15:15 +0530, Harish Krishnaswamy wrote: > Hi friends, > > This mail is to announce that Srinivasa Ragavan (srag) is joining me > to assume the responsibilites as maintainer of the Evolution project. > > Most of you already know Srini (as he is fondly referred to by the Evo > folks) - having interacted with him on IRC, mail or in person during > GUADEC 2006. He is one of our best and most energetic hackers. A few > of his notable contributions include the Evolution Attachment Bar, the > Vertical View for mails, integrating Evolution with the GNOME keyring > and the GNOME VFS backend etc. He has also been prolific in building > the student community in India as part of the Novell Open Source > Internship Program and has mentored students on the Global search, > Cairo integration, migration to gtk-print etc. > He is also looking after the addressbook module in Evolution and > GtkHTML and has been handling the release management partly during the > last development series. > Thanks Harish for this opportunity. I will do my very best to make Evolution a better enterprise quality groupware client. > Srini is already busy seeding the Planning page for Evolution Two > Twelve. Please join the discussions at > http://www.go-evolution.org/Evo2.12. I welcome your suggestions. Please feel free to add your thoughts to the page. Cheers, Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Bug in main_system_beep?
On Sat, 2007-03-31 at 10:05 +0100, Karl Relton wrote: > > I'm not sure what you mean by 'It has to go for STABLE and trunk > branches', I'll leave that to you. I mean that it has to be committed to those two SVN repositories. -Srini > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Spliting evolution into several programs
Hi Diego,
On Sat, 2007-03-31 at 21:28 +0200, Diego González wrote:
> hi,
>
> yesterday i gave a stab at spliting evolution into 3 components, attach
> is a preliminary patch.
>
> The patch does the following things:
> 1) it creates three shells for Mail, Calendar and Addressbook
> 2) each shell does not have the switching buttons (but the menu is still
> present although it does not do anything)
> 3) the settings components are only shown where they belong
> 4) modifies the "New" menu so that it only shows the meaningful
> components inside each application.
>
> Now, this is a "Bonobo-based" split (in that it uses bonobo as the basis
> of the split (ie. there is only a new shell for each component, but the
> components are still there), and there are several problems:
This is same as what I have demoed in last GUADEC (Vilanova 2006). I
have attached that pre-alpha patch that I have used in my demo. But I
felt that it shouldn't be the way to go. I can list the problems with
this approach.
1. Account setup lies with Mailer (Exchange/GW will have issues around
this)
2. Plugins aren't associated to any components. The EPlugin framework
has to load the plugins depending on the component loaded.
3. Though the shell gets invoked multiple times, the window pops out but
the process dies after that as it creates a new view out of it.
Ideally for the split we should do the following things before that
1. Move the account setup out of Mailer
2. Move away from libbonoboui to Gtk based menus
3. Have the shell interface for a all-component view (like what is there
today)
4. Have evolution-mail, evolution-calendar, evolution-contact, etc as
separate binaries. They should have a main function, that creates a
GtkWindow and creates the menus, toolbars, preferences dialog and partly
the required plugins. Some of this can be achieved via the shell
library, need to explore more on this.
>
> a) not all the plugins can be used
> b) the system that lets you add an address from the mailer does not work
> as it requires functionality that belongs to the Address book component.
> c) It is a Bonobo split, meaning that all the components and mostly
> useless bonoboUI code is still there
> d) I don't really know what to do with the memos and notes components
> that belong to the calendar.
They too can be separate apps. Althought the calendar provides a unified
view.
>
> All in all this can be the begining of a crusade to remove BonoboUI (the
> rest of the bonobo that is used in evolution is for communication with
> EDS, but i believe there is plan and even a patch to port it to DBUS)
> from Evolution and split it into 3 components, it only took me 3 hours
> without knowing anything at all about evolution.
>
DBUS port is to replace BONOBO in eds for IPC etc. It has no other stuff
here in Evolution.
-Srini
PS: The patch use to apply on pre-2.8. Im not sure of the trunk.
> Other thing that might also be needed is to put the addressbook UI to
> edit contacts into EDS this way there would be no inter-component
> dependencies.
>
> Last but not least i don't know how the exchange plugins work and thus i
> don't know if this split breaks it and in which ways it does.
>
> Nevertheless i hope it shows a path for future work, i believe that if
> evolution gets rid of the BonoboUI code contributors will find an easier
> way into the code. I also say "it shows a path" because i don't think i
> will have enough time to remove BonoboUI code.
>
> I hope this inspires some hackers.
>
> Best regards,
> Diego
>
> PD: i think the patch and files is everything i modified to make the
> thing work, in case there is something left, just drop me a line.
> ___
> Evolution-hackers mailing list
> Evolution-hackers@gnome.org
> http://mail.gnome.org/mailman/listinfo/evolution-hackers
Index: e-component-registry.c
===
RCS file: /cvs/gnome/evolution/shell/e-component-registry.c,v
retrieving revision 1.58
diff -u -p -r1.58 e-component-registry.c
--- e-component-registry.c 2 Jun 2006 17:32:19 - 1.58
+++ e-component-registry.c 13 Jul 2006 18:06:12 -
@@ -143,7 +143,7 @@ set_schemas (EComponentInfo *component_i
}
static void
-query_components (EComponentRegistry *registry)
+query_components (EComponentRegistry *registry, const char *component_id)
{
Bonobo_ServerInfoList *info_list;
CORBA_Environment ev;
@@ -151,8 +151,12 @@ query_components (EComponentRegistry *re
const GList *l;
char *query;
int i;
+ gboolean loaded=FALSE;
- if (registry->priv->init)
+ if (registry->priv->init && !component_id)
+ return;
+
+ if (component_id && (e_component_registry_peek_info_offline(registry, ECR_FIELD_ALIAS, component_id) != CORBA_OBJECT_NIL))
return;
registry->priv->init = TRUE;
@@ -174,7 +178,7 @@ query_components (EComponentRegistry *re
for (language_list=NULL;l;l=l->next)
language_list = g_slist_append(language_
Re: [Evolution-hackers] Spliting evolution into several programs
On Sun, 2007-04-01 at 13:22 +0200, Diego González wrote: > On Sun, 2007-04-01 at 13:45 +0530, Srinivasa Ragavan wrote: > > This is same as what I have demoed in last GUADEC (Vilanova 2006). I > > have attached that pre-alpha patch that I have used in my demo. But I > > felt that it shouldn't be the way to go. I can list the problems with > > this approach. > > > > 1. Account setup lies with Mailer (Exchange/GW will have issues around > > this) > I see. > > > 2. Plugins aren't associated to any components. The EPlugin framework > > has to load the plugins depending on the component loaded. > > Yes, this is true, i forgot to say that i disabled eplugin because of > this same reason, but it should not be difficult to check the class of > the plugin and load it according to this. > > > 3. Though the shell gets invoked multiple times, the window pops out but > > the process dies after that as it creates a new view out of it. > > > > > > Ideally for the split we should do the following things before that > > > > 1. Move the account setup out of Mailer > Ok, the interace for the ConfigComponentes could be migrated to eplugin > for example and the setup of accounts could be present in *all* the > applications, alternatively the account configuration windows could be > pushed to EDS (libedataserverui), as it should be common to every > component. This particular work has been referred as UAM (Unified Account Management). I would put a strong dependency on this work before we think of split. Or else except mailer, no other is useful. > > > 2. Move away from libbonoboui to Gtk based menus > Yeah, but this requires *A LOT* more work, i think that if we could get > a split based on bonobo, then the components could be moved one by one > from bonobo, depending possible on how much the people used them or > according to the expect number of people that could contribute. > > Moving definetly away from bonobo if the split is done this way is > something that a user should not see, only developers. I agree. This is a soft dependency. We can still live with out this in split view. Just that the individual binaries got to be BonoboWindow and have bonoboui instead of the gtk ones. > > > 3. Have the shell interface for a all-component view (like what is there > > today) > > Well to do this *without* bonobo and making it easier we could launch > each application if the switcher buttons are used, i don't know it it is > optimal but i think it would be the easier thing other wise we could > probably need to recreate bonobo. And if so, it is better to stay as we > are today, at least bonobo has been debugged extensively. Just dont change the existing things. Add the split binaries part of the component, this requirement would be taken care automatically. > > > 4. Have evolution-mail, evolution-calendar, evolution-contact, etc as > > separate binaries. They should have a main function, that creates a > > GtkWindow and creates the menus, toolbars, preferences dialog and partly > > the required plugins. Some of this can be achieved via the shell > > library, need to explore more on this. > > Like my patch?, i have a library that is called libshell that contains > everything in shell/ but the main functions and what was under > libeshell. Similiar, I would say. Main lies in the respective components. You may not launch the components via the bonobo interface, but pack them directly. But leave the mail-component.c for the multiple-component view as what is present today. Preferences will be launched directly instead of the shell interface. Just the basic stuffs like plugins, etc (could be more) will be part of the libeshell. No bonobo query stuff should be here. > > > > > > > > > > a) not all the plugins can be used > > > b) the system that lets you add an address from the mailer does not work > > > as it requires functionality that belongs to the Address book component. > > > c) It is a Bonobo split, meaning that all the components and mostly > > > useless bonoboUI code is still there > > > d) I don't really know what to do with the memos and notes components > > > that belong to the calendar. > > > > They too can be separate apps. Althought the calendar provides a unified > > view. > > > > > > > > All in all this can be the begining of a crusade to remove BonoboUI (the > > > rest of the bonobo that is used in evolution is for communication with > > > EDS, but i believe there is plan and even a patch to port it to DBUS) > > > from Evolution and split it into 3 components, it only took me 3 hours &g
Re: [Evolution-hackers] libebook scalability
On Mon, 2007-04-02 at 01:12 +0200, Øystein Gisnås wrote: > I discovered a bottleneck for addressbook performance with large > addressbooks. Details at > http://n800evolution.blogspot.com/2007/04/libebook-scalability.html Looks fine to commit. > > A proposed fix is attached. I'm not sure if order matters when > returned from the backend? Does anyone know? If not, g_list_reverse > can be omitted. Atleast here the order wont matter. Im sure that there are more such bottle necks. It will be nice task to take these up. Øystein? -Srini. > > Øystein > ___ > 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] libebook scalability
Ross, On Mon, 2007-04-02 at 09:11 +0100, Ross Burton wrote: > On Mon, 2007-04-02 at 09:03 +0200, Øystein Gisnås wrote: > > I'd also love to create scripts, code and test data to test > > performance of some of the most important functions. Then we would be > > able to track performance over time in a more scientific way. > > http://burtonini.com/bzr/eds-tests/ This sounds really great. If you have the bugs/patches please post them across. -Srini. > > Check that out with bzr and you get a few tools: > > 1) a dummy backend for libedata-book. Ask for a contact and you get the > same one back. As for a contact list and you'll always get the same 10. > Ask for a book view and (mwhaha) you'll get 10 contacts. This makes > profiling the EDS infrastructure easier as the backend has almost zero > overhead. I should probably reduce the number of contacts returned in a > book view as malloc tends to swamp the profiles now. > > 2) eds-bookview. A test application that will open and repeatedly > request book views for a given number of times and URL. For example: > > $ eds-bookview --uri dummy:/// --repetition 10 --silent > > Will visibly do nothing for a few minutes but EDS will be very busy. > Attach a profiler and come back 10 minutes later to discover that EVCard > parsing is still primary bottle neck in eds-dbus. > > Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Mail Maintainership
Hi friends, It is with great pleasure I announce that Matthew Barnes joins Varadhan as Mail maintainer. Matthew (mbarnes) is well known by every one who stays on IRC, reads mailing lists and follows bugzilla statistics. He has been doing a fantastic work with Evolution mailer and is contributing lots of quality patches. His joining will help the team review more patches. Welcome on board Matthew Barnes !!! -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Language selector in gtkhtml
Hi Andreas, On Mon, 2007-04-02 at 22:51 +0200, Andreas wrote: > Hi, > > I'm interested in the bounty provided by Novell > http://www.gnome.org/bounties/Mailer.html#127530 (the language > selector). > The widget used in the image seems to be a bit unconvenient to me so > I'm not sure whether I should really use it. I prefer using a combo box, which displays the selected language and on open shows a list of languages with configure or so. Please do reply over the hackers list if you need any help. -Srini. PS: Harish can be contacted through kharish at gnome dot org. > To my mind the best solution would be something like a GtkMenuToolButton > (those buttons with an arrow next to them, like the new-mail button in > evolution). > However I will not be able to use GtkMenuToolButton directly as it > conflicts with the obsolete GtkToolbar api used by the editor component. > But also a combobox would be a possibility. > I'd like to hear your opinion. > Rodo seems to have quit developing gtkhtml > and I'm not able to write mail to harish using "kharish at novell dot > com". Novell's mailer daemon tells me that the user account was expired. > Whom to cotact? > > greets, > Andreas > > > ___ > 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] libebook scalability
On Mon, 2007-04-02 at 13:51 +0100, Ross Burton wrote: > On Mon, 2007-04-02 at 10:18 +0000, Srinivasa Ragavan wrote: > > This sounds really great. If you have the bugs/patches please post them > > across. > > http://bugzilla.gnome.org/show_bug.cgi?id=425464 Looks fine. Approved on bugzilla. -Srini > > Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Spliting evolution into several programs
On Mon, 2007-04-02 at 18:40 +0200, Diego González wrote: > how do you envision this UAM to be? a separete app? something like a > control panel applet? pluggable? Varadhan/Sankar: Can you guys bloat the idea here? -Srini. > > I can try to make the current account system a separate application and > them improve it from there as needed. > > > Diego > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Spliting evolution into several programs
On Wed, 2007-04-04 at 15:03 +1000, Andrew Cowie wrote: > On Tue, 2007-04-03 at 21:14 +0530, Srinivasa Ragavan wrote: > > Can you guys bloat the idea here? > > I think that's the first time I've ever seen "please bloat this > software" as a design request from a manager. > Of course, I meant 'float the idea'. :) -Srini > I'm impressed :) > > AfC > Sydney > > ___ > 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] UAM
Hi Diego, IIRC UAM targets removing ESources and merging them with EAccount. The way calendar, addressbook creation would change wrt groupwise, exchange. When taking these up, it has to be taken with a larger vision. I think the idea of moving the account setup as a capplet/application sounds nice, but I feel that first let us discuss out the approach/design before you implement it. It would surely save lots of effort. Sankar/Varadhan/Harish: Can guys share your thoughts here? Thanks Srini. On Thu, 2007-04-05 at 17:05 +0200, Diego González wrote: > Hi, > > i have been trying to remove the account manager from evolution and > write an application for it. > > This is the current state of affairs: > > It is mostly working, i have removed some settings though as i though > some of them should be in the mailing component itself: > > * Signatures > * Defaults (it deals with stuff that is just for a mailer) > > I'm temped to remove some other things such as: > > Receiving options tab (it deals only with email, and thus it can be on > the mailing component itself) > > > Other than that the beast is almost finished, i will post it as soon as > everything works. > > Diego > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UAM
Hi Diego, I have created a page in the wiki to capture the discussions around UAM http://www.go-evolution.org/UAM I have added few most important points that should be covered part of UAM. Other hackers would be updating the wiki directly. I feel that you can start looking into the first bullet which can help you understand what the rest of the bullets are. Im sure that you have touched some part of the dialog separation already. IMHO it might not be a huge effort to do the actual implementation, but would require a very careful design. Feel free to ping me on irc. Im 'srag' on #evolution. -Srini. On Thu, 2007-04-05 at 21:53 +0200, Diego González wrote: > On Fri, 2007-04-06 at 01:20 +0530, Srinivasa Ragavan wrote: > > Hi Diego, > > > > IIRC UAM targets removing ESources and merging them with EAccount. The > > way calendar, addressbook creation would change wrt groupwise, exchange. > > When taking these up, it has to be taken with a larger vision. I think > > the idea of moving the account setup as a capplet/application sounds > > nice, but I feel that first let us discuss out the approach/design > > before you implement it. It would surely save lots of effort. > > > > Sankar/Varadhan/Harish: Can guys share your thoughts here? > > I didn't know how you envisioned wanted this UAM to work, so i just did > this to use it as a base for further development. > > Actually your email previous email was the first news that i had about a > UAM, i don't even know what the requirements for it are > > Diego > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] triggering a receiving automatically
Looks achievable through mail-remote. Not sure, if the functionality is completely implemented/supported. You can hack it for sure. -Srini. On Sat, 2007-04-07 at 00:03 +0200, Joachim Kluge wrote: > I have Xubuntu Edgy and spool my mail via getmail to /var/mail. The app > mail-notification notifies my instantly of new mails with the help of > FAM (File Alteration Monitor). But how can I make Evolution to fetch new > mails without manual interaction without constant polling? E.g. per > D-Bus or script? > > Thanks, Joachim Kluge > > ___ > 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.10.1 Evolution-Data-Server 1.10.1 GtkHTML 3.14.1 and Evolution-Exchange-2.10.1 released
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.10.1. You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.14/gtkhtml-3.14.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.10/evolution-data-server-1.10.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.10/evolution-2.10.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.10/evolution-exchange-2.10.1.tar.bz2 Upgrade Notes : Evolution 2.10.x is the stable series of 2.10 development. Release Notes = Evolution: == Bug fixes: #343195 - Hiroyuki Ikezoe #332765 - Christof Krüger #424795 - Karl Relton #352713 - René Stadler #400241 - Matthew Barnes #415562 - Wang Xin #401539 - Ebby Wiselyn #356523 - Martin Olsson #426487 - Simon Zheng #426829 - Simon Zheng #406933 - Jeff Cai #380843 - Jeff Cai #388789 - Elijah Newren #301149 - Gilles Dartiguelongue Updated translations: Inaki Larranaga Murgoitio (eu) Claude Paroz & Stéphane Raimbault (fr) Jakub Friedl (cs) Pema Geyleg (dz) Claudio Saavedra (es) Peter Bach (da) Ignacio Casal Quinteiro (gl) Evolution-data-server: = Bug fixes: #425512 - Simon Zheng #388788 - Matthew Barnes #362726 - Thomas Klausner Updated Translations: Inaki Larranaga Murgoitio (eu) Ignacio Casal Quinteiro (gl) Evolution-exchange: == Updated Translations: Jorge González (es) Pema Geyleg (dz) Inaki Larranaga Murgoitio (eu) Ignacio Casal Quinteiro (gl) GtkHTML: === Bug fixes: #374869 - Sankar #419350 - Sebastien Bacher Updated Translations: Ignacio Casal Quinteiro (gl) Pema Geyleg (dz) Inaki Larranaga Murgoitio (eu) Claudio Saavedra (es) Reporting Bugs If you have problems with 2.10.1, 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. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also 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/ Thanks, Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Protocol communication tracking
Set CAMEL_VERBOSE_DEBUG flag in the environment and start Evolution. You can see the logs. I hope this is what you meant. -Srini On Tue, 2007-04-10 at 13:45 +0200, Per Eriksson wrote: > Dear list, > > After experiencing problems with receiving mail through POP from a > specific server, I would like to do some own testing before posting > something in Bugzilla. > > Is there anything built into Evolution to take a look at communication > problems yourself? > > ___ > Best Regards > Per Eriksson > Sweden > [EMAIL PROTECTED] > ___ > 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] UAM
On Tue, 2007-04-10 at 07:02 -0400, Sankar P wrote: > On Thu, 2007-04-05 at 17:05 +0200, Diego González wrote: > > Hi, > > > > i have been trying to remove the account manager from evolution and > > write an application for it. > > Why ? It is for SPLIT. We are trying to remove account manager from Mail. Where to place it (Shell/Evolution or as a capplet) is in the discussion stage. If you have some good thoughts, share it with us :-) -Srini > > > I am not sure what we want to achieve by creating another > capplet/application for configuring a new account. Is it because we can > pre-configure accounts ? (and that is the only thing that I could think > of) IIRC, evolution-gconf-tools module and ximian-account-setup tool > does this already. > > If simplifying the preferences is what you two are looking for, I think > it will be sufficient if we just get rid of the instantaneous > click-and-apply model and start using buttons to launch dialogs with > not-so-commonly-used-options. Once we do not show all the options, the > preferences will not look so crowded. > > As somebody was once mentioning, firefox also has as many configuration > options as Evo has. And the way in which it is presented, (See attached > Screenshot) makes it look simple whereas in Evo we show all the options, > as in http://www.codinghorror.com/blog/archives/000734.html > > > > > This is the current state of affairs: > > > > It is mostly working, i have removed some settings though as i though > > some of them should be in the mailing component itself: > > > > * Signatures > > Signatures are not part of Account Manager. The only thing that accounts > and signature have in unison is that an account can have a default > signature. > > > * Defaults (it deals with stuff that is just for a mailer) > > > > I'm temped to remove some other things such as: > > > > Receiving options tab (it deals only with email, and thus it can be on > > the mailing component itself) > > So where are you going to display all these ? Some of the information in > the receiving options page is so imporatant that without it some > account-types may not work at all (Like SOAP-Port for GW). > > > > > > > Other than that the beast is almost finished, i will post it as soon as > > everything works. > > I don't understand the need for detaching the account setup from > Evolution. > > > > > Diego > > > > ___ > > Evolution-hackers mailing list > > Evolution-hackers@gnome.org > > http://mail.gnome.org/mailman/listinfo/evolution-hackers > > > Sankar > Novell Evolution Hacker ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnuCash print problem patch
Paul, Yes. Before getting into the patch, can you let us know the issue the patch is addressing? It would be helpful while reviewing the patch. -Srini On Thu, 2007-04-12 at 21:41 +1000, Paul Andreassen wrote: > Hello, > > Is this where gtkhtml is maintained? If so could someone look at this patch > and tell me if it acceptable for inclusion. I'm not sure I understand how > all the library code goes together. > > Thanks, > Paul > ___ > Evolution-hackers mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution integration into bespoke database
Hi Kye, I really dont understand the work you are doing and the use cases too. But if this is what you are trying to achieve, you can write a camel transport provider to do this. Evolution has two providers (SMTP and sendmail) which sends the mail from Evolution. In your case, it has to save/store the DB or whatever. The account you create should specify that as the provider for sending so that it works out clean. Look into evolution-data-server/camel/providers/ for sendmail and smtp. You may have to create one more there for your provider. -Srini. On Fri, 2007-04-13 at 10:31 +1000, Kye Macdonald wrote: > Hello All, > > Posted on the wrong mailing list so re-posting here. > > We are in the process of developing an inhouse database and CRM > package and I want to integrate Evolution as its mail client. ATM we > have the database spawning a new evolution email message with all the > contact details in without a problem. What I would like it to do > though is once you press send have the database lift the content from > the email and save it. We have a work around that picks up the mail > from the mail server but I would like the database to interact > directly with evolution. > > Has anyone done this already or know a straight forward path to > achieving this? > > regards, > > Kye Macdonald > ___ > Evolution-hackers mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnuCash print problem patch
On Mon, 2007-04-16 at 22:14 +1000, Paul Andreassen wrote:
> On Friday 13 April 2007 16:54, Paul Andreassen wrote:
> > On Friday 13 April 2007 03:13, Srinivasa Ragavan wrote:
> > > Paul,
> > >
> > > Yes. Before getting into the patch, can you let us know the issue the
> > > patch is addressing? It would be helpful while reviewing the patch.
> > >
> > > -Srini
> > >
> > > On Thu, 2007-04-12 at 21:41 +1000, Paul Andreassen wrote:
> > > > Hello,
> > > >
> > > > Is this where gtkhtml is maintained? If so could someone look at this
> > > > patch and tell me if it acceptable for inclusion. I'm not sure I
> > > > understand how all the library code goes together.
> >
> > Thanks for the reply.
> >
> > When printing or print previewing of a GnuCash report the font changes from
> > the screen font to an unset and unchangeable one. In my case it changes
> > from the screen font of "San Regular 10" to "Serf Regular 12". This
> > results in very large printed reports.
Quoting your previous patch.
> --- gtkhtml-3.10.3/src/htmltext.c.old 2007-04-12 21:09:20.259210176
> +1000
> +++ gtkhtml-3.10.3/src/htmltext.c 2007-04-12 21:20:36.621387496
> +1000
> @@ -1214,12 +1214,16 @@ html_text_prepare_attrs (HTMLText *text,
> pango_attr_list_insert (attrs, attr);
> }
> } else {
> - if (fabs (painter->font_manager.magnification - 1.0) >
> 0.001) {
> - attr = pango_attr_size_new
> (painter->font_manager.var_size*painter->font_manager.magnification);
> + if (painter->font_manager.variable.face != NULL) {
> + attr = pango_attr_family_new
> (painter->font_manager.variable.face);
> attr->start_index = 0;
> attr->end_index = text->text_bytes;
> pango_attr_list_insert (attrs, attr);
> }
>
Im not clear why you you have to insert another attribute here. Also you
dont check for fabs as it was doing earlier.
> + attr = pango_attr_size_new
> (painter->font_manager.var_size*painter->font_manager.magnification);
> + attr->start_index = 0;
> + attr->end_index = text->text_bytes;
> + pango_attr_list_insert (attrs, attr);
> pango_attr_list_splice (attrs, text->attr_list, 0, 0);
> }
> >
> > This patch sets the font for text areas during printing but I don't
> > understand why it already does the right thing for the screen. My patch
> > still has a placement problem for some characters. The C and T in the
> > follow pngs show the problem.
> >
> > Thanks again,
> > Paul
>
> The GnuCash report print bug is listed at
> http://bugzilla.gnome.org/show_bug.cgi?id=350408
>
> After looking further into the problem, it appears that GnomePrint doesn't
> have a setable default font. And because the pango attrs don't set a font
> face or size if the required font is the default, the result is the items are
> printed in GnomePrint default of "Serf Regular 12". My patch changes this to
> explicitly set the pango attrs resulting with the items printed in that font.
>
> As for the character placement problem, it appears to be a problem only with
> the [Dejavu] Sans and [Dejavu] Serf fonts at point sizes 9 and 10 when
> printing. This maybe a Ubuntu 6.06 problem.
>
> Looking at gtkhtml-3.14.0/src/htmlprinter.c from the most recent source, it
> appears that the new gtk_print allows the setting of a default font. Please
> make this user accessable even if its in a gconf file.
> HTMLPainter *
> html_printer_new (GtkWidget *widget, GtkPrintContext *context)
> {
> const PangoFontDescription *desc;
> HTMLPrinter *printer;
> HTMLPainter *painter;
>
> printer = g_object_new (HTML_TYPE_PRINTER, NULL);
> printer->context = g_object_ref (context);
>
> painter = HTML_PAINTER (printer);
> html_painter_set_widget (painter, widget);
> desc = pango_font_description_from_string ("sans 8");/* FIXME font
> hardcoded*/
IIRC the widget is the GtkHTML widget. It can be easy to get the widget
style / font description from GtkHTML widget and set it here instead of
GCONF something else. That way, it may be consistent from what is shown
also. Does that suffice you?
-Srini.
> painter->pango_context = gtk_print_context_create_pango_context
> (context);
> pango_context_set_font_description (painter->pango_context, desc);
> return painter;
>
> }
>
> My web page on this problem with fixes is at
> http://members.iinet.com.au/~paulone/gnucash/
>
> Thanks,
> Paul
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.11.1 , Evolution-Data-Server 1.11.1 , GtkHTML 3.15.1 and Evolution-Exchange-2.11.1 released
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.11.1 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.15/gtkhtml-3.15.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.11/evolution-data-server-1.11.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.11/evolution-2.11.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.11/evolution-exchange-2.11.1.tar.bz2 Upgrade Notes : Evolution 2.11.x is the unstable series of 2.12 development. What is New ? = Evolution: == New in 2.11.1: Improved SPAM support (Srinivasa Ragavan) Bogofilter plugin (Mikhail Zabaluev) Spinner for progress indication (Srinivasa Ragavan) Improved Backup/restore plugin (Srinivasa Ragavan) Improved Groupwise status tracking (Sankar) Improved GtkPrint support (Matthew Barnes) Bug fixes: #211082: Contact merging support on creation (Ebby Wiselyn) #429422 and #419469: Code cleanups (Matthew Barnes) #415985 and #416028: Fix crash in calendar (Wang Xin) #419524: Fix incorrect includes (Matthew Barnes) #426812: Refactor the printing infrastructure (Matthew Barnes) #353662: Signature list now scrollable using keyboard (Baris Cicek) #423766: Fix saving of mail attachments (Matthew Barnes) #343195: Get total number of mails with CAMEL_FOLDER_TOTAL if the folder is junk folder. (Hiroyuki Ikezoe) #383953: Fix message count display (Matthew Barnes) #332765: More intelligent message selection (Christof Krüger) #424795: Fix system beep (Karl Relton) #352713: Update parent rows when a child row changes (René Stadler) #400241: Don't #include since we don't install that file (Matthew Barnes) #411331: Fix the message selection (Srinivasa Ragavan) #375577: Correctly capitalize SpamAssassin (Priit Laes) #387619: Remove use of deprecated icon names (Rodney Dawes) #373116: Migrate from GnomeColorPicker to GtkColorButton (Matthew Barnes) #373837: Migrate from GnomeFontPicker to GtkFontButton (Matthew Barnes) #271851: fix startup notification problem (Stephen Cook) #259606: Added support for middle click to open the component in new window (Michael Meeks) #396645: Show only cert files in filechooser (Gilles Dartiguelongue) #426816: Refactor the printing infrastructure (Matthew Barnes) #329168: Add missing mnemonic widgets (Andre Klapper) #408423: Code cleanups and several memory leaks (Daniel Gryniewicz) #353922: Fix a duplicate keyboard shortcut (Diego Escalante Urrelo) #401539: Fix a crasher (Matthew Barnes) #356523: Copies the file uri and decodes it before trying to attach the image (Martin Olsson) #243241: Show only enabled accounts on composer (Paul Iadonisi) #430559: Added mnemonics. (Vinod) #426743: Corrected typo "asychronous" (Elizabeth Greene) #404233: change "E-Mail" to "Email" (Andre Klapper) #426487: Date is garbled in contacts preview pane on locale "ja_JP.PCK" (Xiurong Simon Zheng) #426829: Code cleanups (Xiurong Simon Zheng) #406933: Call gettext() on the EConfigItem labels (Jeff Cai) #380843: Fix time format translations (Jeff Cai & takao.fujiwara) #426481: Fix Typo Assitant (Elizabeth Greene) #404764: Fix typos and reword a string (Andre Klapper) Updated Translations: David Lodge (en_GB) Yair Hershkovitz (he) Daniel Nylander (sv) Djihed Afifi (ar) Jakub Friedl (cs) Duarte Loreto (pt) Laurent Dhima (sq) Hendrik Richter (de) Evolution-data-server: = Bug fixes: #383686: Use g_mkdir_with_parents (Ross Burton) #322105: Fix for non-junk messages to learn ham. (Srinivasa Ragavan) #418971: E-D-S requires GLib 2.10 now; remove dead backward-compatibility code for GLib < 2.8 (Matthew Barnes) #360240: Remove unused variable. (Matthew Barnes) #360619: Fix "incompatible pointer type" warnings (Matthew Barnes) #405495: Don't mix declarations and code (Jens Granseuer) #360807: Fix a couple of memory leaks (Chris Heath) #400970: Remove marshallers that are in GLib already (Ross Burton) #413173: Fix up the documentation (Ross Burton & Matthew Barnes) #420933: Copy the recurrence ID string so it doesn't disappear on us. (Patrick Ohly) #426893: Added support from address fields in LDAP addressbook. (Caolan McNamara) #422883: Build fix for SUN LDAP (Wang Xin) #424837: Allow contact creation to fail, and propagate the error b
Re: [Evolution-hackers] e_contact_get_const api doesn't work anymore since a few weeks on debian/unstable
On Tue, 2007-05-01 at 20:35 +0200, Julien Puydt wrote:
> Hi,
>
> I had wonderful code (of course) working wonderfully (of course) since
> long. Hélas! This week, I recompiled and ran it to discover it doesn't
> work anymore: the e_contact_get_const api seems to return NULL whatever
> the contact.
>
> On #evolution, evaSDK could reproduce the problem, and told me to report
> to this list.
>
> Snark
>
> PS: I do have a minimalist example, which should help :
> #include
>
> /* gcc -Wextra test.c -o test `pkg-config --cflags --libs libebook-1.2`
> */
>
> int
> main (int argc,
>char *argv [])
> {
>const gchar *vcard =
> "BEGIN:VCARD\n"
> "VERSION:3.0\n"
> "FN:Test\n"
> "TEL;TYPE=Video:sip:[EMAIL PROTECTED]"
> "UID:pas-id-463224CE\n"
> "REV:2007-04-30T19:15:39Z\n"
> "CATEGORIES:Test,Group\n"
> "TEL;TYPE=Home:sip:[EMAIL PROTECTED]"
"TEL;TYPE=Home;TYPE=VOICE:sip:[EMAIL PROTECTED]"
"TEL;TYPE=CELL:123.123.123.123\n"
See it works now.
-Srini.
> "END:VCARD";
>EContact *econtact = NULL;
>
>g_type_init ();
>
>econtact = e_contact_new_from_vcard (vcard1);
>
>g_print ("Home phone: %s\n", e_contact_get_const (econtact,
> E_CONTACT_PHONE_HOME));
>
>g_object_unref (econtact);
>
>return 0;
> }
> ___
> 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] GnomeDruid migration
Gillies, On Thu, 2007-05-10 at 11:05 +0200, Gilles Dartiguelongue wrote: > Hi list, > > I looked at the sources to get a feel of how easy it would be to migrate > from GnomeDruid to GtkAssistant. I started some work on the startup > config plugin and on the new mail account glade part. At that point, > trying to create a new account just crashes evolution, so I decide to > look deeper. > > I found that currently wizards are intricated with notebooks in > e-utils/e-config.c. Although it worked relatively well with GnomeDruid, > I tried to adapt it to GtkAssistant without much success. It seems there > is no easy way to get references to previous and next page other than by > calculating the prev/next page id with GtkAssistant. On the other hand, > integrating new pages into an assistant seems really easy. > > So, what should be done here, indefinitely keep the current > implementation or get rid of one more part of libgnomeui and simplifying > evo's implementation ? I would prefer to move to GtkAssistant but then it should still support the existing EConfig structure. Hula/Groupwise/Exchange and other providers will directly hook into EConfig via EPlugins. I haven't yet seen much into GtkAssistant but it should be possible to get it working. -Srini. > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GnomeDruid migration
On Thu, 2007-05-10 at 16:07 +0200, Gilles Dartiguelongue wrote: > Le jeudi 10 mai 2007 à 15:40 +0530, Srinivasa Ragavan a écrit : > > > > > > So, what should be done here, indefinitely keep the current > > > implementation or get rid of one more part of libgnomeui and simplifying > > > evo's implementation ? > > > > I would prefer to move to GtkAssistant but then it should still support > > the existing EConfig structure. Hula/Groupwise/Exchange and other > > providers will directly hook into EConfig via EPlugins. > > > > I haven't yet seen much into GtkAssistant but it should be possible to > > get it working. > > great, > > I should add that I wanted to make the necessary changes to the plugins. > too if necessary (I believe that mixing GnomeDruid and GtkAssistant is > not cool at all unless you want to express your mad g_object skills :) ). I dont want to mix really. We can stick to Assistant. Just before that, I'm planning for some one to take up UAM. In which case, I want to push Account setup/Assistant out of Mailer to Shell or it can very well be part of Control-Center as a capplet from Evolution. (Just a floating thought!) In which case, Im afraid that the work could be duplicated or obsolete. Too early to say but stuff to think off. > > As I said, the biggest difference is that GnomeDruid bases it's > operations on the access of next and previous page through pointers > which is not the case with GtkAssistant. We could simulate that > obviously but I think the result wouldn't be easy to either debug or > maintain. I really don't want unmaintainable code, its pain. I prefer to refactor the EConfig code to fit Assistant's architecture, if that make sense. But as I have said earlier, I haven't yet looked into GtkAssistant. But it shouldn't be hard to file apis against it to get better APIs just for the sake of easier migration. We may then do it at the next release or so. -Srini > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.11.2 , Evolution-Data-Server 1.11.2 , GtkHTML 3.15.2 and Evolution-Exchange-2.11.2 released
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.11.2 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.15/gtkhtml-3.15.2.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.11/evolution-data-server-1.11.2.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.11/evolution-2.11.2.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.11/evolution-exchange-2.11.2.tar.bz2 Upgrade Notes : Evolution 2.11.x is the unstable series of 2.12 development. What is New ? = Evolution: == New in 2.11.2: Mail notification plugin with libnotify and panel tray support (Srinivasa Ragavan) Bug fixes: #407104: Makes the GNOME Clock applet able to correctly start Evolution. (Matthew Barnes) #355919: Fixes evolution crash when display depth set to 8 on sparc machine (Xiurong Simon Zheng) #427789: Allow cut/copy and paste an appointment/meeting/task with localized characters (Xiurong Simon Zheng) #337616: Fix "make distcheck" errors. (Matthew Barnes) #334966: Fix for crash on close. (Srinivasa Ragavan) #325966: Clicking folder tree submenu title now opens/closes the tree (Christian Neumair) #435610: Run gtk-update-icon-cache in uninstall-hook (David Farning) #330098: Selecting Copy on Right-clicking any memo list now works (Naresh) #424055: Fixed resizing of contact list dialog. (Øystein Gisnås) #417797: Copy and move of contacts between address books now works correctly (Øystein Gisnås) #404239: Included a missing row columns in contacts minicard view (Øystein Gisnås) #358250: Change field Organization to Company in AddressBook (Javier F. Serrador) #325118: Add translator comments for a string (Andre Klapper) #378441: Mnemonics added for FROM/SUBJECT/TO headers in message pane (Ebby Wiselyn) #380750: Make force-shutdown work in Solaris (Wang Xin) #414195: Fix build break (Loïc Minier) #425506: Fix a crash when clicking the Edit button (Xiurong Simon Zheng) #324982: Fix warnings at program startup (Hiroyuki Ikezoe) #375234: Fix a crash when syncing with iPod (Vitaliy Ischenko) #325965: Fix a crash when selecting "mark messages as read" on a Maildir subfolder (Ilkka Tuohela) #398145: Tango icons for preferences window (Jakub Steiner) #432867: Changed default attribute for file from 0755 to 0644 (Milan Crha) Updated Translations: Jorge Gonzalez (es) Evolution-data-server: = New in this release: * EContact optimization from (Oystein Gisnas and Milan Crha) Bug fixes: #420496: Add support to cut/copy contacts in composer (Ebby Wiselyn) #339160: Implement the sync method for Addressbook backends (Ross Burton) #414191: Type fixes for EContact ints (Loïc Minier) #433782 and #336574: Optimise vCard folding (Oystein Gisnas and Milan Crha) #431135: Fix a crash when modifying a calendar event (Rob Bradford) #274035: Importing a Vcard with attached photo data is now possible (Jonty Wareing) #361138: Fix a crash when double clicking text widget in calendar in indic locales (Matthew Barnes) Other Contributors: Jules Colding Updated Translations: Jorge Gonzalez (es) Evolution-exchange: == Bug fixes: #433967: Add a CLEANFILES rule to remove a schema file (Matthew Barnes) #418852: Use GLib's i18n support instead of Camel's (Matthew Barnes) Updated Translations: Jorge Gonzalez (es) GtkHTML: === Bug fixes: #407363: Added mnemonic for paste quotation menuitem (Bharathi Gauthaman) Other contributors: Fix filenames in CLEANFILES and other cleanups. (Matthew Barnes) Updated Translations: Washington Lins (pt_BR) Funda Wang (zh_CN) Jakub Friedl (cs) Reporting Bugs If you have problems with 2.11.2, 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. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also 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/ Thanks, Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.or
Re: [Evolution-hackers] go-evolution.org wiki & spam
Hi Gilles, I dont see the spam in the Main_Page. Am I seeing elsewhere? -Srini On Tue, 2007-05-15 at 11:32 +0200, Gilles Dartiguelongue wrote: > Hi guys, > > if this is off-topic, please redirect me to the proper mailing list. > > I've noticed since yesterday some spam across the wiki. Digging a bit I > found that it was kind of widespread (see > http://www.go-evolution.org/Special:Recentchanges if you are not > convinced). The main page has some spam in it too but I can't fix it > since I don't have the proper rights. > > I've seen a user's comment asking "what about turning anonymous editing > off ?". Will this be done ? The version of wikipedia seems a bit old > too, is an upgrade planned ? > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] go-evolution.org wiki & spam
On Tue, 2007-05-15 at 15:40 +0200, Gilles Dartiguelongue wrote: > Le mardi 15 mai 2007 à 18:51 +0530, Srinivasa Ragavan a écrit : > > Hi Gilles, > > > > I dont see the spam in the Main_Page. Am I seeing elsewhere? > > click on "see source as text". > It's in a tag with css style making it invisible to users (namely id="wyikol" style="overflow:auto; height: 1px; ">) Ah! Caught it. Removed. -Srini. > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Addressbook Maintainership
Hi friends, It is with great pleasure I announce that Ross Burton joins me as "Addressbook maintainer". Ross is already the maintainer of Sound Juicer, Devil's pie, Contacts, Dates and Tasks. He has contributed many patches in Addressbook during his development of Contacts and also wrote the DBus port of Evolution Data Server. He started reviewing addressbook patches recently. I will be looking into the Evolution portion of Addressbook and Ross will be looking more into EDS portion of Addressbook. I'm sure that his addition to the team will help improve the performance and memory usage of Addressbook and review more patches. Welcome on board Ross !!! -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Addressbook Maintainership
On Fri, 2007-05-18 at 19:23 +0100, Ross Burton wrote: > On Fri, 2007-05-18 at 18:00 +0000, Srinivasa Ragavan wrote: > > It is with great pleasure I announce that Ross Burton joins me > > as "Addressbook maintainer". Ross is already the maintainer of Sound > > Juicer, Devil's pie, Contacts, Dates and Tasks. He has contributed many > > patches in Addressbook during his development of Contacts and also wrote > > the DBus port of Evolution Data Server. He started reviewing addressbook > > patches recently. > > To avoid upsetting my colleagues I should point out that I've barely > touched Contacts and Dates (Chris Lord, Thomas Wood, Rob Bradford and > Tomas Frydrych are the main authors IIRC). Ah! Sorry for the trouble > > Thanks for the warm welcome, I hope to do a better job maintaining EDS > than I do with Sound Juicer... All the best :) -Srini. > > Obviously one of my main goals for the next two release cycles is to > land and polish the DBus port of EDS. I've started planning this on the > wiki[1], but extra hands are always appreciated. If anyone would like > to help, please just say. > > Regards, > Ross > > [1] http://www.go-evolution.org/DbusPort > ___ > 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] Proposed fix for bug 311512
Karl, This is a killer problem and you have been rocking with your patches on this right from the beginning. Awesome work! I'm sure that the Mailer hackers would review it asap and It will be great if we can get this in for 2.11.3. Thanks for your great work! -Srini. On Sun, 2007-05-20 at 19:29 +0100, Karl Relton wrote: > Hi friends > > I have submitted new patches to bugzilla for bug > > http://bugzilla.gnome.org/show_bug.cgi?id=311512 > > > One changes e-d-s as Fejj suggested, the other does the Evolution side > so it will only do mail-notification on 'truely' new messages. > > I'll be pleased if you could review. > > Karl > > > On Thu, 2007-04-26 at 09:29 -0400, Jeffrey Stedfast wrote: > > not completely correct... > > > > when you trigger an event on a CamelObject, it first fires the "prep" > > callback, which is what camel-folder.c:folder_changed() is (note that it > > returns bool) > > > > A prep event handler is the first handler called (event handlers are > > fired sequentially, in order of connection - /not/ in parallel) and gets > > to decide if the event propagates by returning TRUE (or FALSE if it > > should be blocked - that's how freeze/thaw works). > > > > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Mail notification plugin names/descriptions
On Sun, 2007-05-20 at 19:45 +0100, Karl Relton wrote: > Srini > > I was looking at your new mail-notification plugin in Evolution. > > All is fine, and I can see that you would want to 'add' the plugin > rather than merge or replace the new-mail-notification plugin that > already existed. > > However, I think the two should have their names & descriptions changed > to avoid confusing the new user who can't be expected to know the subtle > difference between the two. > > How about the following two name/description pairs: > > New Mail Notification (Tray) > Notifies the user with tray icon and a notify message when new mail > arrives. > > New Mail Notification (Dbus) > Generates a D-BUS message when new mail arrives for use by other mail > notification programs. I was thinking of changing this to dbus-mail-notification. -Srini. > > > Also, doesn't your new plugin allow > http://bugzilla.gnome.org/show_bug.cgi?id=127516 > to be finally closed? > > Karl > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > Hi, > > > > I discovered last week that there is an attempt to resurrect libical > > from non-maintainership, merge all of the patches from various forks, > > and start making sane releases again[1]. Are the evolution team as > > whole interested in merging their changes to libical upstream and > > depending on it to be installed when a release is made with all of the > > relevant changes? libical isn't exactly a small library, and statically > > linking it is a waste of memory for everyone. > > I vaguely recall the biggest diff being timezone handling. > > > I'll happily start working on extracting the changes to EDS and pushing > > them into the new libical repository, if the Evolution team as a whole > > agrees that the fork of libical will be dropped. > > I'd suggested waiting to see a pattern of stable releases before moving > externally, but getting the patches upstream would be good. Sounds very reasonable to me. -Srini. > > -JP ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?
Ross, It will be great if you can mail the details on the address book stuff as well. I would like the libebook clients like OOo, etc to comment on this. -Srini. On Sun, 2007-05-20 at 11:29 +0100, Ross Burton wrote: > Hi, > > Last week I committed a patch to libebook, and want to commit a patch to > libecal[1], which removes private functions and types from the installed > headers. This has several consequences: > > - e_cal_view_new() is removed > - ECalListener is removed > - ECalViewListener is removed > > I believe that nobody is using these functions apart from libecal > itself, so this removal is safe. However, I'd appreciate it if anyone > writing advanced clients to EDS (like Zimbra or Brutas) remove their > currently installed headers, apply the patch, and rebuild. > > Thanks, > Ross > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=438727 > ___ > 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] Removal of implementation details from public API, any breakages?
Ross, >From the current discussion, it looks like we are safe. Can we do something like this for this release before we dung them out? #ifdef E_D_S_DEPRECATED #include #endif -Srini. On Mon, 2007-05-21 at 10:32 +0100, Ross Burton wrote: > On Mon, 2007-05-21 at 12:15 +0530, Srinivasa Ragavan wrote: > > It will be great if you can mail the details on the address book stuff > > as well. I would like the libebook clients like OOo, etc to comment on > > this. > > The addressbook changes are very similar: > > - e_book_view_new() is not public > - EBookListener and EBookViewListener are not public > > As before, these are not usable outside of libedata-book, so clients > should not be aware of their existence. > > I've had a quick look at the Zimbra Evolution code and it appears to not > use these either. > > Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases
Frederic, One reason why me and Harish didn't want to tag is that we are able to map the svn revision number to a particular release. I hope isn't so difficult to get that from the ChangeLog/configure.in/NEWS commit logs. At least that is how we do while preparing NEWS file for a dot release to know what went in since the last release. If you have better points, We are open for it. Nothing against it :) -Srini. On Mon, 2007-05-21 at 17:19 +0200, Frederic Crozat wrote: > Hi Evolution / E-D-S maintainers, > > it appears that since CVS to SVN migration, no evolution / e-d-s release > was followed by a SVN tag creation in /tags. > > These tags are very useful for you, maintainers but also for > contributors and vendors when they try to search for changes between > releases. > > Could you try to create those missing tags and make sure they are > created when releasing new tarballs in the future (I guess somebody > script was not migrated correctly to SVN ;) ? > > Thanks you in advance. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removal of implementation details from public API, any breakages?
On Mon, 2007-05-21 at 12:38 +0100, Ross Burton wrote: > On Mon, 2007-05-21 at 11:33 +0000, Srinivasa Ragavan wrote: > > >From the current discussion, it looks like we are safe. Can we do > > something like this for this release before we dung them out? > > > > #ifdef E_D_S_DEPRECATED > > #include > > #endif > > The patches consist of removing functions or headers from the install, > these cannot be deprecated because they are still used by EDS itself. Hmm. Fine. Just go ahead then :) -Srini. > > I don't think there needs to be any notice: the headers and functions > are implementation details of libebook and libecal, and are not possible > to use outside of the implementation of libebook/libecal. > > Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Missing svn tags for e-d-s / evolution 2.18 releases
On Mon, 2007-05-21 at 18:57 +0200, Frederic Crozat wrote: > Le lundi 21 mai 2007 à 16:36 +0000, Srinivasa Ragavan a écrit : > > Frederic, > > > > One reason why me and Harish didn't want to tag is that we are able to > > map the svn revision number to a particular release. I hope isn't so > > difficult to get that from the ChangeLog/configure.in/NEWS commit logs. > > At least that is how we do while preparing NEWS file for a dot release > > to know what went in since the last release. > > > > If you have better points, We are open for it. Nothing against it :) > > I don't really see what it causing problem here : just tags the release > corresponding to the commit for configure.in / NEWS / Changelog. It > isn't really a big problem if there is another commit for the tag > operation in SVN. I didn't say it a problem. I'm saying that the TAG would map directly to a revision in svn which would be the revision of the commit of those files. You can achieve what you want with tag with just revision number itself. In case of CVS, you can't do this. If it is of difficulty to map to a revision, no problem in resuming that again. -Srini. > > Or am I missing something ? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GMail+iTunes GUI suggestion for Evolution 3
On Sun, 2007-05-27 at 02:56 +0200, Louise Hoffman wrote: > Dear hackers > > I just found this screenshot of a GMail iTunes layout for Thunderbird > 3, and thought it could be considered for Evolution as well? > > Bug with text that explains the features. > https://bugzilla.mozilla.org/show_bug.cgi?id=306125 Nice thought. I think we got to brainstorm on how this would work on large mail boxes. But then, I would prefer if a EPlugin can be worked out in place of the message list. More plug-able views. > > Screenshot > https://bugzilla.mozilla.org/attachment.cgi?id=207965 > > And here is a screenshot of Lotus Notes with 3 vertical panes and > tabs. I really like the compact sender and subject pane. > https://bugzilla.mozilla.org/attachment.cgi?id=266215 It is already there since 2.8 -Srini. > > Could something like that be considered for Evolution 3? > > Lots of love, > Louise > ___ > 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] GMail+iTunes GUI suggestion for Evolution 3
On Sun, 2007-05-27 at 21:13 +0200, Louise Hoffman wrote: > > Nice thought. I think we got to brainstorm on how this would work on > > large mail boxes. > > Doesn't it scale? I don't know anything about UI design. I needs some good usability testing. It may not end-up here, may be derived from this. > > > But then, I would prefer if a EPlugin can be worked > > out in place of the message list. More plug-able views. > > Pretty impressive, if so radical changes can be made by a plugin! Just that hooks need to be in place. -Srini > > It is already there since 2.8 > > I love it! =) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GMail+iTunes GUI suggestion for Evolution 3
On Sun, 2007-05-27 at 21:27 +0200, Louise Hoffman wrote: > > I needs some good usability testing. It may not end-up here, may be > > derived from this. > > Should I send the link to another mailinglist then? there is a usability list gnome usability discussion, but I'm not sure if it falls there. Novell has a usability team that does usability testing with different profile of users and derives results out them. http://www.betterdesktop.org -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.10.2 Evolution-Data-Server 1.10.2 GtkHTML 3.14.2 andEvolution-Exchange-2.10.2 released
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.10.2. You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.14/gtkhtml-3.14.2.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.10/evolution-data-server-1.10.2.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.10/evolution-2.10.2.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.10/evolution-exchange-2.10.2.tar.bz2 Upgrade Notes : Evolution 2.10.x is the stable series of 2.10 development. Release Notes = Evolution: == Bug fixes: #322105: Allows non-junk training on non-junk messages (Srinivasa Ragavan) #386503: Help Menu or F1 now works (Matthew Barnes, Götz Waschk) #329168: Calendar Preferences Mnemonics now work (Andre Klapper) #353662: Signature list now scrollable using keyboard (Baris Cicek) #423766: Fix saving of mail attachments (Matthew Barnes) #437584: Fix compilation warnings (Gilles Dartiguelongue) #425506: Fix a crash when clicking the Edit button (Xiurong Simon Zheng) #440493, #440566: Fixed a German typo (Hendrik Richter) #432702: Fixed typo in Brazilian Portuguese translation Washington Lins) #439049: Fixed "Invliad Time..." error dialog in "ja" locale (Wang Xin) #434981: Attachment bar now shows the correct number of attachments (Matthew Barnes) #380750: evolution --force-shutdown now works on Solaris (Wang Xin) #319504: Fix configure for LDFLAGS=-Wl,--as-needed. (Karsten Bräckelmann) #388789 : Fixed a subtle bug in autotools checks for iconv (Matthew Barnes) #112166: (bugs.launchpad.net) Fixed french translation (Stéphane Raimbault) #334966: Fix for crash on close. (Srinivasa Ragavan) #432867: Changed default attribute for file from 0755 to 0644 (Milan Crha) #330098: Selecting Copy on Right-clicking any memo list now works (Naresh) #351729: Removed unnecessary/broken windows (Milan Crha) #424055: Fixed resizing of contact list dialog. (Øystein Gisnås) #325965: Fix a crash when selecting "mark messages as read" on a Maildir subfolder (Ilkka Tuohela) Other Contributors: Exchange Folder loading performance improvement (Varadhan) Corrected arguments in API gtk_clipboard_set_text() (Xiurong Simon Zheng) Added Russian help files translations (Sergey Mironov) Updated Spanish help files translations and screenshots (Jorge Gonzalez) Updated French help files translations and screenshots (Claude Paroz) Remove included file (Parthasarathi Susarla) Updated Translations: Hendrik Richter (de) Jakub Friedl (cs) Ivar Smolin (et) Claude Paroz (fr) Yannig MARCHEGAY (oc) Gabor Kelemen (hu) Jorge Gonzalez (es) Peter Bach (da) Djihed Afifi (ar) Washington Lins (pt_BR) Evolution-data-server: = Bug fixes: #322105: Allow not-junk training on non-junk messsages (Srini) #424373: Fixes APOP Authentication Vulnerability issue. (Sankar P) #431135: Fix a crash when modifying a calendar event (Rob Bradford) #438765: Fixed a German typo (Hendrik Richter) #439050: Fixed "Invliad Time..." error dialog in "ja" locale (Wang Xin) #425535: Don't submit path of EDS for segv_handler. (Frederic Crozat) #388788: Fixed a subtle bug in autotools checks for iconv (Matthew Barnes) #425129: Fix a crash when the timezone has no name (Pascal Terjan) #425129: Add a timezone name for Australia/Perth (Pascal Terjan) #318176: Code cleanups (Ross Burton) #431722: Add support for parsing GEO properties (Dodji Seketeli) Other Contributors: Claude Paroz Updated Translations: Hendrik Richter (de) Jorge Gonzalez (es) Duarte Loreto (pt) Yang Zhang (zh_CN) Peter Bach (da) Evolution-exchange: == Bug fixes: #406155: Fix for Exchange crasher (Varadhan) #433967: Fixed "make distcheck" (Matthew Barnes) #439121: Fixed a German typo in evolution-exchange (Hendrik Richter) Other fixes: Fix for broken folder subscriptions (Varadhan) Updated Translations: Hendrik Richter (de) Yang Zhang (zh_CN) GtkHTML: === Bug fixes: #347347: Selected text is now spoken by Orca correctly (Yi Jin) #420493: Setting the width of a rule doesn't take effect (Ebby Wiselyn) #349773: Support searching UTF-8 strings. (Xiurong Simon Zheng) #331813: Fix URL highlighting of sip/h323 addresses (Gilles Dartiguelongue) Updated Translations: Washington Lins (pt_BR) Funda Wang (zh_CN) Peter Bach (da) Reporting Bugs If you have problems with 2.1
Re: [Evolution-hackers] Removal of DFSG non-free RFCs in evolution-exchange
Hi Øystein, On Wed, 2007-05-30 at 08:03 +0200, Øystein Gisnås wrote: > It seems like http://bugzilla.gnome.org/show_bug.cgi?id=366250 didn't > make it for the 2.10.2 release monday. Unfortunately, it didn't make it to Monday's release, as Varadhan had to look at some critical exchange issue in the stable release build. > Could someone (Varadhan?) please give a statement on whether you want > to remove those docs and suggest a timeframe for that? I don't have/see a issue on removing that. I would leave it to Varadhan to decide. -Srini. > > Cheers, > Øystein Gisnås > Debian Evolution Maintainer Team > ___ > 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's UI, consistency and codebase
On Thu, 2007-05-31 at 00:17 +0200, Gilles Dartiguelongue wrote: > Hi list, > > big title, but probably not a big deal (at least for the case I'm > exposing) > > After reading [1] and [2] and part of the HIG, I started to see lots of > bad dialogs in evolution. I've already tried to fix some of this UI > badness (imap-features plugin) but today I came across the "Customize > View" dialog and I wanted to talk about it :) > > First thing that hit me was that it didn't use GtkTreeView and that it > doesn't understand _ markup. I think that can be moved to GtkTreeView and shouldn't have a issue. Patches are welcome :). It is not that, it doesn't understand markup. The '_' is there to provide key accelerator in visible UI items, and it isn't stripped of at those places. I don't think that '_' makes any sense in the table/row. > I know evolution has its own ETable widget > and that it does thing that evolution needs and gtk+ doesn't provide but > why use this widget here ? It is that, we have moved to GtkTreeView to in lots of places and we have list of places where we want to move and don't want to move. Message list is a place where we don't want to move. > > The second thing is the "Edit" button. It is not the same as everywhere > I looked in the preferences window, this is bad. This can be fixed. > > Last point is, why is the mail view headers fixed (like not look like > buttons) in 2.10 and not the other views as well (memos, calendars, > contacts) In few themes, Ive seen that it looks like a table header, but not in all themes. If you have seen this 2.10, may be with a right theme. Im sure that this should be fixable in widgets/table. I don't think it would right to fix all the other themes for this. -Srini. > > Please advise. > > [1] http://bugzilla.gnome.org/show_bug.cgi?id=364385 > [2] http://www.go-evolution.org/User_Interface > ___ > 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
