Re: [Evolution-hackers] Imminent critical SSL problem in evolution 3.10
On 10/29/2014 02:56 AM, Milan Crha wrote: we look on the same thing in a different ways. My point of view: the *current* stable version is 3.12.x (right now 3.12.7). This current stable version doesn't suffer of the issue described for 3.10 version. It's not my fault that your distribution uses obsolete evolution version; I do not have any influence on it. The bug as such is fixed, in the *current* stable version. The 3.10 is dead for the upstream. Nonetheless, my intention was to provide a fix for such distributions anyway, in a way I chose. I'm not going to commit the patch to the gnome-3-10 branch, I do not like to add changes into dead branches, where no releases will be done. Rather than burying the patch in Bugzilla or on a dead git branch, I suggest sending it to distributor-l...@gnome.org with an explanation of what versions are affected. Then if any other complaints crop up you can show that distributors still shipping an unsupported Evolution release have been informed. Matthew Barnes ___ 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] e-d-s build problems
Hi Christian, I've been having the same build issue on Debian. Revert this commit and you should be able to build again: https://git.gnome.org/browse/evolution-data-server/commit/?id=a2790163af4d3f375a778055d0e2699207dfd050 Matthew Barnes - Original Message - Hi, I don't know why and when the problem started, but at the moment I cannot build e-d-s/master. I removed all my local/libs and tried a fresh checkout with jhbuild, same result DSO missing from command line to work around the issue I changed some Makefiles and added the missing symbols/lib manually to _LIBADD (see below) evo and e-d-s compile now, but I'm not 100% convinced of the result, since evo deleted my Personal addressbook the first time I started evo... Is something wrong with my system or are other people seeing the same issues? (I know there has been a similar thread earlier this year for 3.12) Christian --- /usr/bin/ld: evolution_addressbook_factory_subprocess-evolution-addressbook-factory-subprocess.o: undefined reference to symbol 'e_dbus_subprocess_object_skeleton_new' evolution_addressbook_factory_subprocess_LDADD $(top_builddir)/private/libedbus-private.la \ src/evolution-data-server/calendar/libecal/e-cal-client.c:832: undefined reference to `e_dbus_calendar_call_close' .libs/libecal_1_2_la-e-cal-client.o: In function `cal_client_get_backend_property_sync': libecal_1_2_la_LIBADD = $(top_builddir)/private/libedbus-private.la \ --- src/evolution-data-server/calendar/libedata-cal/e-data-cal.c:569: undefined reference to `e_dbus_calendar_complete_open' libedata_cal_1_2_la_LIBADD = \ $(top_builddir)/private/libedbus-private.la \ evolution_calendar_factory_subprocess_LDADD = \ $(top_builddir)/private/libedbus-private.la \ ___ 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 mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Fwd: e-d-s build problems
- Forwarded Message - From: schaarsc schaa...@gmx.de To: Matthew Barnes mbar...@redhat.com Sent: Friday, September 26, 2014 10:11:45 AM Subject: Re: [Evolution-hackers] e-d-s build problems Hi Matthew, thank you! reverting Revert this commit and you should be able to build again: https://git.gnome.org/browse/evolution-data-server/commit/?id=a2790163af4d3f375a778055d0e2699207dfd050 solved my problem too. Christian ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit based Evolution composer status and future
On Mon, 2014-06-09 at 16:57 +0200, Tomas Popela wrote: Hi, the WebKit based composer was commited into master with [0]. Awesome! Congrats on landing that - that's a pretty major feature and I'll start testing it immediately. Also I have to say I'm thrilled to finally see GtkHTML die for good! Matt ___ 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] Introspection enablement for libecal - huge changes needed?
On Tue, 2014-05-20 at 11:07 +0200, Patrick Ohly wrote: Aren't you going to run into the same problem with a GObject-based proxies for these libical objects? The proxies are reference-counted, the libical objects are not, so they may go away before their proxies do. This would leave the proxy with a dangling pointer or (if it somehow tracks the lifetime of the owner of the object) in a state where it is unusable. I imagine the GObject proxies would need to hold their own copies of libical objects and have some explicit set API to apply changes back to a parent object. It's more expensive, but that's the trade-off for thread-safety. Matt ___ 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] Developing a new protected message complement
On Tue, 2014-04-01 at 11:02 -0430, BECERRA Silvana M SIDOR wrote: Actually, we're analyzing the possibility of going to a more updated version of EVO (we have it on canaima 4.0 based on debian 7.0 and Gnome 3.4.2), but we've had trouble compiling a newer version. Do you know where we can get a compiled version that works? I've never heard of Canaima, but if it's a Debian derivative then Debian's testing or experimental repos would be your best bet for newer Evolution packages. However, to try to clarify a bit, what we mean by protected Email is that when reply/forward (inline mode) a protected message we're allow to write our response but we should not be able to modify the text of none of the old messages. Additionally, although not commented before, the message should also include custom field in the header that consolidates date, from, to, of all old messages in an orderly manner. For that kind of protection to have any real meaning, all messages should be cryptographically signed by their author and attached in full to all replies and forwards. An Evolution extension could conceivably enforce that. The inline editing mode simply copies and pastes the source message body into what's essentially a free-form text editor. Trying to protect the pasted text in a free-form editor widget is pointless because it can be easily spoofed, as can any kind of custom message header. Cryptographically signing each message with a public key or a trusted certificate is really the only way to ensure previous messages are not altered. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit based Evolution composer status and future
On Mon, 2014-03-17 at 20:05 +0100, Patrick Ohly wrote: While I have no say in how Evolution gets developed, I nonetheless would like to warn against merging unstable and known buggy code into master. What if it turns out that the code can't be stabilized in time for the next release? Can it be reverted or will Evolution have to go out with known regressions? The next release following 3.12 will happen in March, 2015. So we have an entire year to stabilize the WebKit composer. Also the HTML library that the composer is currently based on has been dead several years now, and I personally would like to wash my hands of it as soon as possible. I haven't tested the branch in awhile, but I've seen numerous recent bug reports from Milan and Tomas seems pretty responsive in fixing them. As long as that continues after merging, and we have a handle on the major remaining regressions, I think it's a reasonable risk to finish the work directly on the master branch. If things still haven't stabilized by... let's say this year's GUADEC... then we can start discussing a contingency plan for Evolution 3.14. Matt ___ 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] newcomers: How should I compile Evolution?
On Thu, 2014-03-06 at 09:58 +0100, Fabiano Fidêncio wrote: I can bet that (almost) every contributor has a different way to setup the environment, compile and use the fresh compiled Evolution and I'm here to describe the way I do my setup (based on Matthew's setup) :-) Nice instructions! I should transcribe this to a wiki page. Let me amend this with a couple more tricks... I also have three scripts (or just aliases would work too) named: autogen-eds autogen-evo autogen-ews Each of these is basically just... ./autogen.sh --prefix=$PREFIX (yadda, yadda, yadda) This is where I keep the configure options I routinely use for building evolution-data-server, evolution, and evolution-ews, respectively. It's mainly just options like --enable-this or --disable-that, etc. That way I don't have to remember them all or keep them typing them all. Also, a newcomer may not need this but just for completeness, I also have a script named 'stable', which is almost the same as 'unstable', but uses a different PREFIX ($HOME/local/stable). It too references 'common', which is why 'common' is a separate script. I use 'stable' for building our latest stable branch, currently gnome-3-10. It uses a different install prefix so I don't mix files from the two branches. That would be bad. Also, speaking of branches, generic git trick: For me the 'git-new-workdir' script that comes with git is a life saver! It allows you have multiple working directories for the same repo without cloning the whole repo, each checked out to a different branch. That was my biggest complaint with git when I first started using it -- that to switch branches I first had to pack up whatever I was doing in the current working directory, switch branches, and wipe the working directory clean so I don't pick up build artifacts from the other branch. But that increases the build time and slows me down. The 'git-new-workdir' script solves this, but it's not installed in /usr/bin for some reason. You have to dig it out of: /usr/share/doc/git/contrib/workdir or some similar place on your distro. Just copy the script to your $HOME/.local/bin, and do git-new-workdir --help to see how it works. That's my bag of tricks. Matthew Barnes ___ 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] Proposal: Evolution 3.13 Release Schedule
On Mon, 2014-03-03 at 15:51 -0500, Matthew Barnes wrote: Been thinking about our release schedule after 3.12.0, when we break with GNOME and embark on our own annual development/support cycle. I'd like to release updates at a more predictable cadence than GNOME. With the GNOME 3.12.0 and 3.12.1 release dates in mind, I propose the following: - Release stable updates on the 2nd Monday of each month. - Release development updates on the 4th Monday of each month. Another thing I've been thinking about is what to call our stable branch names, starting with 3.12. The usual gnome-3-x branch name is going to be confusing, especially later this year when our version number starts to diverge from GNOME's version number. I suggest just naming the branches after the module name, similar to how GLib and GTK+ do it. e.g. evolution-3-12 evolution-data-server-3-12 evolution-ews-3-12 evolution-mapi-3-12 That sound okay? I don't have a strong preference for the name, other than not using 'gnome' anymore. Matt ___ 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] When talking about branches...
On Thu, 2014-03-06 at 17:06 +0100, Milan Crha wrote: Right, that's the only being active currently from my point of view too (and according to commit log). Should I figure out the right git command and just get rid of those in eds/evo/ews/ema? Yeah, have at it. I think the commands you need are: git branch -r -- list all the remote branches git push origin :branch-name -- deletes a remote branch (I don't really understand the colon, but that's how it works.) Obviously be careful if you try to automate this or use grep or whatever. Matt ___ 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] When talking about branches...
On Thu, 2014-03-06 at 11:40 -0500, Paul Smith wrote: If you have a new-ish git you can use the --delete flag instead of the colon (exactly the same result, but more readable): git push --delete origin branch-name Thanks for the tip, that's much easier to remember. Matt ___ 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] Keep an eye on IMAP this week
Late last week I finally got the IMAPX backend fully ported to use GLib streams directly. I debated whether to push the commits for 3.12, being that it's kinda late in the cycle, but I've been running the code for several days and it seems alright. It's in master now, so keep an eye on IMAP this week. If there's disastrous regressions I'm willing to revert. Note, Camel has actually been using GLib streams since early 3.11, but it was hidden behind the CamelStream API layer. All these commits do is cut out the middle man. It's a significant step toward finally retiring the whole CamelStream API. I'll be porting the POP3 and NNTP backends after 3.12. Those should be easy by comparison. Matt ___ 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] GSoC Ideas
On Tue, 2014-02-11 at 18:18 +0100, Milan Crha wrote: On Tue, 2014-02-11 at 17:21 +0400, Emre Erenoglu wrote: 2) Attachment Detach and Link function This one, from my point of view, doesn't qualify for a GSoC project, basically because it's only a serialization of two actions, which might not make anybody busy for couple weeks. Also, as Andre mentioned on the evolution-list, those detached attachments might not be available, if you move to other machine (supposing you'll move the attachment on a remote protocol, like IMAP, Exchange related, and so on), thus the link to it will be relevant only on one machine, and only until user actually deletes the file (or even better until overwrites it with a content from other attachment, which may then just confuse him/her, even unintentionally and being done by the user him/her-self). It doesn't mean that it cannot live as a bug request, for someone whom would like to play a bit with the code, it's just that it's too simple for a GSoC project, from my point of view. I agree. I think it would be sufficient to just prompt to save the attachments before permanently removing them. The prompt would also double as an are you sure? check to help avoid accidents. Matthew Barnes ___ 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] GSoC Ideas
On Mon, 2014-02-10 at 09:41 -0500, Eldon Ziegler wrote: How about an ability to use a different backend DB, if that does not exist already? I use MongoDB to scoop up my email after Evolution stores it and it would be really great if MongoDB also could be used within Evolution itself. No interest in this, as it would only compound our workload. SQLite is the chosen tool for the job. But you're free to fork Camel if you like. Matthew Barnes ___ 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] GSoC Ideas
On Mon, 2014-01-27 at 17:03 +0100, Fabiano Fidêncio wrote: I'd like to see a student working on Evolution family on this year GSoC (if GNOME is accept as an org, of course). So, I'm starting this thread to keep track/discuss possible ideas and, as soon as we have settled on them, move to Evolution's wikipage. A couple years ago I mentored a GSoC student on a concept demonstration of a GTK-based server-side mail filter editor which would have used the ManageSieve protocol. The plan was to create a working stand-alone demo application for the GSoC project, and then afterward start integrating it into Evolution. The student never finished, but I still think it's a good idea. Matt ___ 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] evolution-data-server build fails with undefined reference to camel_stream_new
On Sat, 2014-01-25 at 12:42 -0800, Kerrick Staley wrote: Building evolution-data-server via JHBuild isn't working for me. The relevant section of the error output is [1], and the full log is attached. Does anyone know why this is happening? Means you have old build artifacts installed and jhbuild doesn't automatically clean up after itself. Just uninstall the old E-D-S and rebuild. Matthew Barnes ___ 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] [Draft] Evolution Road-map for post-3.12
Here's my list. There's a few items on the wiki page I've been dragging along for a few releases now. Those are still on my agenda, even the importer rewrite. https://wiki.gnome.org/Apps/Evolution/Planning310 Additionally I want to really focus on getting Camel's API fixed up well enough to split off from E-D-S and declare stable. I've intended to do that for several years [1], but parts of Camel's API are still a mess and I'm not yet willing to commit to them. Among the things that need done yet are: * Kill CamelStream and all its subclasses and port Camel entirely to GIO-based streams. I'm already making some headway on that. * Move all the filtering logic into Evolution. Camel's filtering logic is already highly dependent on Evolution and not fleshed out well enough to be usable on its own. From there I can more easily make some badly needed improvements under Evolution's umbrella, where API stability isn't an issue. * GMime is Jeff Steadfast's partial fork of Camel, and there's still a lot of shared heritage there. I understand he added a pretty comprehensive test suite, and I'd like to try importing that and adapting it to Camel's current APIs. * Study/cleanup/document the summary database and virtual folders. I still don't really have my head around these areas. The APIs are a mess and nothing's documented. I'd like to spend a little time on it and probably do some refactoring before the split, because I can't maintain this stuff if I don't understand it. * Maybe annotate the API for introspection and generate language bindings? Even if there's no demand for Camel bindings, I think the practice helps promote good discipline and API design and is worth the effort. Between the wiki page items, this stuff, and the usual caring and feeding of the project, I think that's a pretty full plate for me. Matt [1] https://mail.gnome.org/archives/evolution-hackers/2009-November/msg00019.html ___ 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] [PATCH evolution-data-server] imapx: Remove check for NIL separator
On Mon, 2013-12-30 at 00:37 +0100, Lubomir Rintel wrote: This has been tested with MUNI IMAP server along with: Subject: [PATCH evolution-data-server] imapx: Treat BODY[HEADER] as equivalent to RFC822.HEADER Date: Sun, 29 Dec 2013 21:10:57 +0100 Message-id: 1388347857-1479-1-git-send-email-lkund...@v3.sk camel/providers/imapx/camel-imapx-namespace.c | 1 - 1 file changed, 1 deletion(-) diff --git a/camel/providers/imapx/camel-imapx-namespace.c b/camel/providers/imapx/camel-imapx-namespace.c index c86165b..c924d39 100644 --- a/camel/providers/imapx/camel-imapx-namespace.c +++ b/camel/providers/imapx/camel-imapx-namespace.c @@ -93,7 +93,6 @@ camel_imapx_namespace_new (CamelIMAPXNamespaceCategory category, CamelIMAPXNamespace *namespace; g_return_val_if_fail (prefix != NULL, NULL); - g_return_val_if_fail (separator != '\0', NULL); /* Not bothering with GObject properties for this class. */ Thanks for that. I remember not being sure about that assertion when I wrote it. Either the RFC wasn't clear or I missed some fine print. I'll commit this and your BODY[HEADER] patch for the next release. For future reference it's better to submit patches to our bug tracking system [1] so we can... well, track them easier. Matthew Barnes [1] http://bugzilla.gnome.org ___ 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] libecal soname change
On Thu, 2014-01-02 at 11:30 +0100, Patrick Ohly wrote: I just noticed that libecal bumped its soname to libecal-1.2.so.16 in EDS 3.10. The corresponding commit is: commit f30ae26320b359666b345c92405bf87f3f43250a Author: Matthew Barnes mbar...@redhat.com Date: Tue Jul 16 06:34:02 2013 -0400 Bump libecal / libedata-cal soname for API breaks. Matthew, can you elaborate what that break is? The libdata-cal bump was to cover the preceding commits: commit f9ee1477151f2747745f2e90e1a7d34bc992b931 Author: Milan Crha mc...@redhat.com Date: Tue Jul 16 12:05:30 2013 +0200 Insufficient return values from e_cal_backend_get_object/_list() These also returned ECalComponent, but it cannot hold a vCalendar, which is returned when the component has detached instances. commit 9da18738a150915500a44e0e7c54d9ef1eb4f3c4 Author: Milan Crha mc...@redhat.com Date: Tue Jul 16 09:01:55 2013 +0200 Bug #704220 - Incorrect runtime check in e_data_cal_respond_send_objects() The libecal bump looks like it may have been a mistake on my part. I must have been under the impression the client-side API changed as well. Sorry about that. Matthew Barnes ___ 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] The wiki is the new official homepage
In light of [1], the Evolution website on http://projects.gnome.org/ has been decommissioned. The Evolution wiki is our new official homepage. http://wiki.gnome.org/Apps/Evolution The website content was aging anyway, and was a pain to maintain. About the only thing I was updating regularly were the tarball download links, which are now on the front wiki page: https://wiki.gnome.org/Apps/Evolution#Get_the_Source_Code I'll be mining the Evolution website for any remaining useful tidbits that aren't already on the wiki, and attempting to set up forwarding. Matthew Barnes [1] http://blogs.gnome.org/mccann/2013/12/17/lets-face-it/ ___ 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] Junk filtering controls and logic are confusing
On Sat, 2013-11-23 at 10:48 -0600, Michael Ekstrand wrote: The particular working of the junk filtering pane (Preferences - Mail Preferences - Junk) is confusing, and the functionality it controls is (A) hard to understand and (B) arguably incorrect. Indeed. You're wading into a mess here. The junk filtering logic bounces between Camel and Evolution. Camel's filtering (both junk and otherwise) is highly dependent on Evolution and at some point I'd like to move it all to Evolution and get Camel out of the filtering business entirely. (The relevant Camel APIs badly need an overhaul as well, as they're ancient, error-handling is pretty much non- existent and they block like crazy.) 1. What all does 'Check incoming messages for junk' control? Everything? Just the junk plugin (spamassassin/bogofilter)? Does checking or unchecking it affect whether custom headers are scanned? - Potential UI fix: the options for everything that is pre-empted by disabling junk checking should be disabled when the checkbox is cleared I think the option should be removed entirely and be made per-account, but that may be a bit of a project. At the moment, only IMAP accounts have their own junk filtering options, and I believe those options are secondary to this master switch. Disabling the Check incoming messages for junk turns off everything: custom header checks, address book lookups, and junk filtering software. 2. What option is ignored if a match for custom junk headers is found? - The code suggests that the address book and and junk filter plugin logic are both ignored if custom headers are found Correct: headers first, then address book, then filtering software. I think it's meant to be in order of fastest to slowest. As soon as any of those tests determine the message to be junk, processing stops. 3. What happens if there is no junk plugin (bogofilter/spamassassin) installed? UI makes it looks like the custom headers will work, and address book checking will work. However, the code seems to disagree: looking at the junk_test function in camel-filter-search.c, it looks like everything is just bypassed if there is no junk filter installed. Yeah you're right. Probably even my handiwork. The header and address book checks should run regardless. That's a valid bug. In my mail setup, I run SpamAssassin on the server (as a Postfix milter). I want Evolution to check the spam headers set by the server, but not to mess with running bogofilter or spamassassin or anything like that locally. Further, since my server's SpamAssassin doesn't know anything about my address book, I want the address book lookup to override the custom header check. The processing order I mentioned above would have to be changed. I don't have any strong opinions about that since I just use Bogofilter. The UI makes it ambiguous as to whether this is possible. Looking through the code, to the extent that I understand it so far, it looks like it is not. If I have no junk filter plugin, then Evolution will not do any checking, including for custom headers. If I have one, then I'm double-scanning my mail and slowing down Evolution. And the address book check doesn't interact with the header check. It would be clearer if the UI read more like a checklist: [ ] First check this... [ ] Then check this... [ ] Then check this... In particular, a few things I am immediately interested in making happen: 1. Making address book checks preempt spam header checks 2. (maybe) figuring out why the spam header check isn't doing anything 3. Making spam header address book checks work without a spam filtering plugin 4. Making spam filtering UI disable things to show how it works Sounds great to me! Polishing up those options and unbreaking whatever's broken would be much appreciated. Matthew Barnes ___ 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] Junk filtering controls and logic are confusing
On Sat, 2013-11-23 at 15:44 -0600, Michael Ekstrand wrote: I've cooked up a pair of not-yet-tested patches that address (1) by moving the address book check before the header check and (3) by moving the 'do we have a junk filter?' test to right before the junk filter is actually moved. Sounds good. For (1) please add a comment to the junk_test() function describing the rationale for the new ordering, for posterity. * Keep 'Check incoming messages for junk' as the top, top-level check box. Have it enable/disable the following options, which are indented under it: * 'Skip junk detection if sender is in my address book' * 'Lookup in local address book only' * 'Check custom headers for junk flags' * 'Use external junk filter' drop-down (invisible if no plugin available, junk filter config UI is subordinate to this checkbox) * 'Delete junk messages' as top-level sibling of 'Check…', at the bottom of the pane * Get rid of the 'Option is ignored…' notice Sounds good on paper. Maybe you could post a screen shot when you get things reworked? A word of warning about Glade, if you choose to use it, is to carefully check over the changes it makes after saving because it loves to corrupt our .ui files. Glade eats any widget types in the .ui file it doesn't understand and sometimes doesn't get along well with our one-letter 'E' prefix, and silently omits anything it had trouble reading when saving back to disk, thereby corrupting the file. More often than not I have to manually audit the changes it makes with git add -p before committing. Matthew Barnes ___ 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] Running Evolution from jhbuild
On Fri, 2013-11-22 at 08:48 -0600, Michael Ekstrand wrote: I can't use the address book subsystem - it says the AddressBook6 service isn't provided by any .service files. I'm using the default moduleset, did 'jhbuild build evolution'. You probably haven't configured your session bus to look for service files in the place where jhbuild installs them. Add something like this to your /etc/dbus-1/session.conf: servicedir/path/to/jhbuilt/share/dbus-1/services/servicedir Or you could just start the services manually from a separate terminal window. That's what I usually do so I can monitor the standard output. Matthew Barnes ___ 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] EDS Documentation Effort
On Mon, 2013-11-04 at 15:18 +0900, Tristan Van Berkom wrote: The goal is to transform the gtk-doc generated html pages into something that actually looks like a reference manual. Before starting on this long and tedious task of going through the symbols one by one and checking them off a huge list, I'd like to share my plans with the list. Hopefully with some of your feedback I can maximize the value of this work. Excellent! I'm happy to help out with this. In the past year or two I've tried to discipline myself to document every new symbol I add, and I've noticed Milan has started doing that now too. So the newer APIs should be in pretty good shape already. A lot of the older APIs are either undocumented or the documentation has... word-rotted... and is no longer accurate. It's a mind-numbing task to fix that stuff up and I've only managed to do it in fits and starts. A concerted effort I think is exactly what we need. o It probably makes sense here to evaluate also if and where there are multiple methods of achieving the same effect in the EDS user facing APIs (some of the e-data-server-utils.c parts might suffer this). In the case there are multiple code paths to the same result, we should take care to deprecate one of them. Agreed. In particular, I suggest not wasting much time on the EBook and ECal APIs, as those have been deprecated for a couple years now and are about ready to be dropped. o One thing I'd like to propose is a unified book for EDS. With a unified documentation package for the whole EDS API (perhaps excluding camel), a much more useful and comprehensive table of contents can be built. Also agreed. I don't know why that hadn't occurred to me already. It would make maintenance easier as well. Yes, Camel docs should remain separate. Camel is destined to be split off from the E-D-S git module and should be considered a base dependency of E-D-S, not really part of E-D-S. Another good high-level goal would be to get all the Gtk-Doc warnings fixed for things like improper gtk-doc syntax in comments, mismatched argument names, etc. It would be great we could enable TESTS = $(GTKDOC_CHECK) in the Makefile.am and require that to pass as part of the release process. Maybe we should take that one library at a time, though. Anyway, big +1 from me on this whole proposal. Matt ___ 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] EDS addressbook api info
On Wed, 2013-10-23 at 00:39 +1100, Timothy Ward wrote: After looking at the latest EDS docs and the info on the latest EDS addressbook API I wondered if there were and docs related to reading the address book info in total all fields to another source, the code I am using is quite old and the addressbook API interface has changed many times and requires rewritting. Do any reference notes exist that would help me with this task. Not quite sure what you mean by reading to another source, but you can obtain all the EContact objects from an address book with e_book_client_get_contacts(). You'll want to pass an S-expression query that just matches everything. I believe the way to do so is: book_query = e_book_query_any_field_contains (); sexp_string = e_book_query_to_string (book_query); e_book_client_get_contacts (client, sexp_string, ...); The query syntax is not very well documented. I gleaned the example above from Evolution code. I can try to elaborate further if needed. Matthew Barnes ___ 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] Regarding addressbook migration test case
On Mon, 2013-10-21 at 18:27 +0200, Tristan Van Berkom wrote: The maintenance in question is pretty simple, every stable release (directly after branching for the next stable release would be the ideal time) a new case needs to be added to the addressbook migration test. I really appreciate this. Perhaps it could serve as a template for other kinds of migration testing in the future. The mbox - Maildir migration back in 3.0 would have been less problematic with something like this. To clarify: New test cases are only *really* needed when the database format changes, right? A test-case-per-version policy is more about maintainers can't be trusted to update tests when needed. Not offended, in fact I agree. Just want to make sure I have the rationale straight. I've tried to make this as painless as possible, in order to add a new release to the list of tested stable releases, one needs to do the following: cd ~/path/to/evolution-data-server make -C tests/book-migration setup-migration git add tests/book-migration/db/3.12/contacts.db gedit tests/book-migration/db/3.12/Makefile (add contacts.db to EXTRA_DIST) For reference, you can see this commit[1] which adds EDS 3.10 to the list of releases to test. Looks easy enough. Best place for these extra steps would be: https://wiki.gnome.org/Apps/Evolution/ReleaseHOWTO Would you mind writing up a new section there (or I can), maybe after Post-Release Updates? Matt ___ 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] Tentative 3.11 schedule
On Mon, 2013-10-14 at 09:48 +0530, samarjit Adhikari wrote: Where did you release 3.10? Evolution 3.10 was released at the same time as GNOME 3.10, available at the usual place (download.gnome.org/sources). I've just been lazy about updating the website lately. Matthew Barnes ___ 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] Tentative 3.11 schedule
I just released 3.10.1 and still haven't seen an official release schedule from GNOME, so I penciled one in for us based on the 3.7 schedule from last year. https://wiki.gnome.org/Apps/Evolution/ReleaseHOWTO#Release_Schedule According to this schedule, the first 3.11 release is due next Monday (October 21st). Let's proceed with that unless GNOME posts something official this week. Matt ___ 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] Testing EEwsConnection's API
On Thu, 2013-10-10 at 11:24 +0200, Fabiano Fidencio wrote: Please, take a look into: http://blog.fidencio.org/2013/10/evolution-ews-testing-eewsconnections.html Nice work! More automated testing is definitely needed. Maybe this could serve as a template for testing the other HTTP-based backends in the future. Matt ___ 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] geocode-glib version
On Sun, 2013-09-01 at 13:12 -0300, Sasa Ostrouska wrote: Hi I was just wondering if is there a special reason to use geocode-glib version 0.99.0 as there is already out a 0.99.2 so would be nice to have in configure.ac geocode-glib = 0.99.0 instead of geocode-glib = 0.99.0 There were substantial API changes on the master branch of geocode-glib that we don't yet support. I don't yet know if 0.99.2 includes those changes or if it's backward compatible with 0.99.0. If it's backward compatible then we can support it for Evolution 3.10, otherwise it has to wait for Evolution 3.11/3.12. Matthew Barnes ___ 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] Evolution EWS: Planning the 3.12
On Mon, 2013-08-26 at 15:48 +0200, Fabiano Fidencio wrote: If you prefer, I can put all these info in the wiki, following the way you have been done for 3.10. It's up to you :-) Nah, no need to duplicate the info. The wiki page in its present format isn't the best place for detailed plans. I was thinking just a line item with a link to your blog post. Matthew Barnes ___ 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] Move IMAPX back to a module library for 3.12
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? Matt ___ 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] Wiki moved
You may have noticed our wiki pages moved from wiki.gnome.org/Evolution to wiki.gnome.org/Apps/Evolution. This happened last Friday at Jon McCann's request. I agreed since he added an automatic redirect from Evolution to Apps/Evolution. What I didn't realize was most of our pages were using absolute instead of relative paths in wiki links, so the move broke all those links. He and I fixed up what links we could find, but keep watch for any other broken links on our wiki. The absolute paths were mostly my fault, but to keep this from happening again use this syntax: /ChildPage (child of the current page) ../SiblingPage (sibling of the current page) Instead of: Apps/Evolution/SomePage (this is an absolute path) Matt ___ 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 Hackfest at GUADEC 2013
Alberto Ruiz (my new boss) organized and led an Evolution hackfest at this year's GUADEC in Brno, Czech Republic. He posted a summary on his blog, for those interested: http://aruiz.synaptia.net/siliconisland/2013/08/evolution-hackfest-2013-redux.html The transition to an annual release cycle, which I brought up before in [1], is a go for next year. The Evolution team was in agreement, and I got no objection from the GNOME release team. It was really fun meeting almost everyone present in person for the first time. Even met Milan Crha for the first time, even though we've been working together on IRC for about *six years* now! I hope we can do this again some time. Matthew Barnes [1] https://mail.gnome.org/archives/evolution-list/2013-July/msg00162.html ___ 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 Mon, 2013-07-29 at 01:26 +0200, Tobias Mueller wrote: Hm. I'm wondering whether this is a problem for the rest of GNOME, too. Do the arguments brought up in this thread apply to Evolution (and friends) only? If no: Would the rest of GNOME also benefit from a different release schedule? If yes: Why would that be? The arguments on favour of a longer cycle seem to be very generic to me. It's difficult to speak to GNOME as a whole because -- GNOME OS visions notwithstanding -- GNOME is a diverse collection of independent projects of different sizes, levels of maturity, activeness and agendas. Different projects of different sizes have different needs. I'd caution against generalizing from one example. The arguments brought up here may not be unique to Evolution, but they're based on observations of how well Evolution development policies are serving the Evolution community. Matt ___ 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, 2013-07-24 at 07:21 -0400, Paul Smith wrote: Not being familiar with Evo development I'm not sure how feasible it is, but ideally part of the change in release cycle would mean divorce from the Gnome version lockstep, and Evo being able to build against multiple versions of Gnome. If Evo were changed to be more of a stand-alone utility (at least optionally), rather than being bundled with Gnome, that would be (IMO) a good thing for users. I've already come to regard Evolution as a GTK+ application rather than a GNOME application. While we do have some (optional) desktop-specific integration for GNOME and Unity, I for one do most of my development on XFCE nowadays. Evolution has also been buildable on multiple GNOME releases for awhile now. For the past several years I've tried to ensure the development branch of Evolution and co. remains buildable on the latest *stable* GNOME development platform, such that our major releases are actually developed for the previous GNOME release. Evolution 3.8, for example, builds on both GNOME 3.8 and GNOME 3.6. I think targeting the latest stable development platform strikes a good balance between utilizing new advancements in the platform and keeping a safe distance from the chaos at the bleeding edge. I don't foresee that policy changing as we transition to a longer release cycle. Matt ___ 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, 2013-07-23 at 10:10 -0400, Matthew Barnes wrote: My feeling is just that at this point in the project's lifespan, our users would be better served by a longer support window. They still want to see improvements and new features, but more than anything I think they just want stability and to see their bugs fixed without waiting half a year. It's just an idea. What do you guys think? It seems like we have a general consensus among developers in favor of a longer release cycle. Next week I think I'll pitch the idea to the user list just to get a sense of the response. To clarify a few points: * I should have been more explicit but I did mean ALL our modules, not just Evolution. EWS, MAPI, and especially E-D-S. I think E-D-S is more in need of a longer support cycle than Evolution itself, since a lot of our stable branch maintenance focuses on the infrastructure and backends provided by E-D-S. IMAP, CalDAV, LDAP, etc. * I see the wisdom in Milan's suggestion of sticking to our current version numbering, but just slowing it down. It might cause some confusion initially, but once we jump ahead of the GNOME release numbers we can't go back. So Evolution 4.0 is off the table. I do still find the year-based numbering appealing: Evolution 2014.x, etc., since there's no major version number to set false expectations for a project that does incremental improvements. And users would be more aware of how old of a release they're using, instead of it being some arbitrary number. And it removes the idiotic lesser version == less mature mentality when comparing two unrelated projects. I just can't figure out what to call the development snapshots. * I think our policy toward stable branch maintenance could be a little more relaxed during the first half of a release cycle in terms of what we allow in. I don't know what that means exactly for us yet, but I have observed RHEL updates do sometimes include new features. Maybe enterprise policies could be a rough guide until we find our footing. * I like Milan's idea of publishing our own release schedule as an .ics file, as in http://www.gnome.org/start/unstable/schedule.ics. Matt ___ 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] Reconsidering our release cycle
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. 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. Obviously there's more details to figure out, but I like the precedent we've set with the 3.8 branch, and I think our users appreciate it too. My feeling is just that at this point in the project's lifespan, our users would be better served by a longer support window. They still want to see improvements and new features, but more than anything I think they just want stability and to see their bugs fixed without waiting half a year. It's just an idea. What do you guys think? Matt ___ 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] Running evolution 3.10
On Tue, 2013-07-09 at 08:34 +0530, Joe Steeve wrote: So, I managed to build it. But, how to run it without screwing my local configuration. The gnome from my distro (Debian Wheezy) is 3.4. Easiest ways are to either run 3.9.x from a separate user account, or install a virtual machine. Matthew Barnes ___ 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] (evolution:30823): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
Can you get a backtrace on that warning, please? G_DEBUG=fatal_warnings gdb evolution - Original Message - From: Reid Thompson reid.thomp...@ateb.com To: evolution-hackers@gnome.org Sent: Monday, June 24, 2013 9:16:30 AM Subject: [Evolution-hackers] (evolution:30823): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. As information, i happened to notice this this morning. (evolution:30823): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: Error executing filter search: Failed to retrieve message: (and (match-all (= (pipe-message /bin/sh -c /home/rthompso/bin/catrootmail) 35)) ) Reid ___ 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 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] (evolution:30823): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
$ G_DEBUG=fatal_warnings gdb evolution /opt/evo/bin/evolution-src (evolution:6219): Gtk-WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files /opt/evo/bin/evolution-src: line 46: 7753 Trace/breakpoint trap (core dumped) $prefix/bin/evolution-env $prefix/bin/evolution $@ $logdir/evo.log.$i 21 2) if I get past 1, if I can re-create the initial error. Type continue (or just c) in gdb. ___ 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] Crashes on webkit-composer Branch - even outside if composer?
On Sun, 2013-06-02 at 23:19 +0200, Joey 4712 wrote: when buildiing Evolution from branch webkit-composer on Arch Linux it crashes after running for about 20 seconds to 2 minutes. That branch is a work-in-progress and should not be used other than by the developers working on it. It will be merged into the master branch once it's deemed feature-complete and stable. Matthew Barnes ___ 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] Backporting EWS GAL changes to 3.8
On Thu, 2013-05-30 at 11:56 +0100, David Woodhouse wrote: We had a local copy of the LZX decompression code, taken from libmspack and then hacked up somewhat to support the variant that the EWS GAL uses. I cleaned up that code and got it accepted into upstream libmspack, and libmspack 0.4 has been released a week or two ago. As part of that process, the libmspack maintainer spotted a number of bugs in our changes. These have all been fixed in the 0.4 release. I've fixed the build in master so that we either need to build with libmspack 0.4 as an additional dependency (recommended), or use a configure option to build with our internal version of the decompression code instead. If you configure without an appropriate libmspack, the resulting error will tell you about the --with-internal-lzx option. That's the right way. A two week-old release is far too new for a stable branch dependency, especially one we're introducing mid-stream. It needs to be optional for now, but at the same time we do want packagers to be aware of it. Aborting the configure script by default with a workaround message if libmspack 0.4 is not present accomplishes that. We're giving special attention to the stable release this cycle, so I'm willing to bend the rules a bit. +1 from me. I think we could remove the internal lzx copy as early as 3.11. Matt ___ 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] Colon is a show-stopper.
On Fri, 2013-05-17 at 11:01 -0400, Mark Filipak wrote: Here is a typical message file: ~/.local/share/evolution/mail/local/cur/1365462216.8388_1.Iris:2,S Can I persuade Evolution to use some other character in lieu of the colon? This is very important to me... it's a show-stopper. No, the colon is part of the Maildir specification. All the files must have the form: unique_name:2,flags Matthew Barnes ___ 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] crash in 3.8.2
On Sun, 2013-05-12 at 16:37 -0300, Sasa Ostrouska wrote: Fontconfig warning: /etc/fonts/conf.d/44-wqy-zenhei.conf, line 11: Having multiple values in test isn't supported and may not work as expected (evolution:11746): Gdk-ERROR **: The program 'evolution' received an X Window System error. Looks like something's wrong with your font configuration. 3.8.2 works fine here. Matthew Barnes ___ 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] Build failures the past several days
On Thu, 2013-04-18 at 11:25 -0400, Matthew Barnes wrote: I think we just need to port the changes here to Evolution: https://git.gnome.org/browse/evolution-data-server/commit/?id=fb9b02e43251b7f4004eb41791f0a3553eeb2b4c I'll take care of it. Should be fixed now for both master and gnome-3-8 branches. Matt ___ 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] Build failures the past several days
On Wed, 2013-04-17 at 16:21 +, Reid Thompson wrote: For the past few days my builds of evolution, and evolution-ews ahave been failing with essentially the same error... Try a clean rebuild. I just did a successful make distcheck on Evolution. Matthew Barnes ___ 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] EDS 3.8.1 build problem
On Sun, 2013-04-14 at 15:56 -0300, Sasa Ostrouska wrote: Hi, I'm trying to upgrade my evolution from 3.6.x to 3.8.x and I get the build brake at the tests. Old build artifacts, most likely. A clean rebuild should fix it. The functions it claims it can't find are right here: https://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-data-server-util.c#n1368 Matthew Barnes ___ 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] Leaving debug symbols in
On Thu, 2013-04-11 at 13:41 -0700, Bob Purvy wrote: How do I keep the symbols from getting removed on 'make install' ? I'm using 2.4.2.1, which I know is way old, but I have to use it for reasons you don't want to know. Add -g to your CFLAGS environment variable and rebuild everything. http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html Matthew Barnes ___ 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] Distinguish interactive and non-interactive EClient-s
On Thu, 2013-03-21 at 12:41 +0100, Milan Crha wrote: This way we've a backward compatibility, only clients which would like to be non-interactive will advertise it, others will work like before. To be able to address the need to disable/enable interactive mode after open, there might be added a boolean property 'interactive-mode' to the client. Maybe it can replace the flag in the e_client_open() call completely. It's not really the client or even the client connection which owns the mode, but rather the backend. The backend can only operate in one mode at a time, since it authenticates or sets up a secure TCP connection on behalf of _all_ clients. I'd suggest a scheme were the client connection can provide the backend with some sort of token which gives the backend permission to interact with the user for as long as that connection is open. When I was working on Ubuntu Online Accounts I learned their signond system used an enum they called UiPolicy which I found appealing. https://code.google.com/p/accounts-sso/source/browse/lib/SignOn/sessiondata.h?repo=signondname=2.4#58 If we rank a similar set of UI policies according to a desired precedence, perhaps like: NO_USER_INTERACTION_POLICY (lowest precedence) ALLOW_NOTIFICATIONS_POLICY ALLOW_MODAL_DIALOGS_POLICY (highest precedence) then the backend could act according to the token with the highest precedence. (ALLOW_NOTIFICATIONS_POLICY could simply submit a hey, this needs your attention! desktop notification in lieu of a dialog, perhaps with an action button that would allow further user interaction.) So for example, if a client submits an ALLOW_NOTIFICATIONS_POLICY token to a backend that only previously had NO_USER_INTERACTION_POLICY tokens, then the backend may now submit a desktop notification if it fails to authenticate or establish a secure TCP connection. If another client comes along and submits an ALLOW_MODEL_DIALOGS_POLICY token to that same backend, the backend would then be allowed to act as it does currently, for as long as it has that token. Does that make sense? Submitting these tokens could be a new EClient method, so we don't have to hack the existing API. Then it's just a matter of tracking tokens on the server-side, which I'm sure is not too difficult. Matt ___ 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] gnome-3-8 branches created
The master branches are now for 3.9 development. Have at it! The gnome-3-8 branches are under a code freeze until the 3.8.0 release on March 25. Matthew Barnes ___ 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] Restructuring direct access mode
I'd like to restructure the new direct access mode for address books a bit for Evolution-Data-Server 3.9.1. Tristan's client-side implementation looks to me like it really wants to be a subclass. It basically intercepts and overrides entire EBookClient methods with its own behavior, which is what subclasses are for. Unfortunately we never anticipated a need for subclassing EBookClient or ECalClient, and they currently lack overridable method pointers in their class structures. I suggest we suffer an ABI bump and correct this for 3.9.1. It's a bit of a backward-compatibility break for anyone already using this feature, but better to make the course correction now while it's still relatively fresh, as it will only get harder to fix with time. Specifically: * Flesh out EBookClientClass and ECalClientClass definitions with synchronous and asynchronous method pointers, similar to what we already have in Camel. Also insert plenty of struct padding for future expansion, while we're at it. * Split direct access into EBookDirectClient and EBookDirectClientView subclasses. * Repurpose the e_book_client_connect_direct_sync() function to instantiate and configure an EBookDirectClient. * Split the direct mode APIs into a new library: libebook-direct * And finally revert the awkward libebook / libebook-contacts split, which I doubt anyone will notice. That would give us a more straight-forward dependency chain: libebook - libedata-book - libebook-direct I already have this partially prototyped, and it's passing the test suite, so I'm confident it will work. To help ease the transition from 3.8 to 3.10, we could add a fake libebook-direct.pc file to the gnome-3-8 branch, which would just require libebook.pc. There's still time to get the libebook-direct.pc file into 3.8.0, which is why I'm bringing this up now. Any objections? Matthew Barnes ___ 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] Gnome Evolution installation error
On Sat, 2013-03-09 at 22:57 +0200, Ebru Akagunduz wrote: How can i fix it? Install evolution-data-server from git first. Matthew Barnes ___ 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] Code help required for evolution hung opening meeting invitation
On Sat, 2013-03-02 at 18:21 +0530, Samarjit Adhikari wrote: If you have any intuition why this problem is happening , do let me know. I shall look into the code and try to fix it. Looks like you're running into a known GObject deadlock. https://bugzilla.gnome.org/show_bug.cgi?id=674885 We can work around it by registering the GType earlier. Matthew Barnes ___ 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] Isolated unit test status report
On Sat, 2013-02-23 at 23:38 +0900, Tristan wrote: This indicates that somewhere, in the client or server, we are leaking references to the GDBusConnections. I've tested this in raw GIO (and added a test case there) to ensure it is indeed possible to stop/start the GTestDBus between tests, the problem is clearly an ugly bug to be fixed in EDS. I suspect this might be related to the factory proxy object that we create in the background and leave lying around as a global variable. We could try letting EBookClient create its own EDBusAddressBookFactory proxy, call its OpenAddressBook method, and then immediately destroy it. That would simplify the code, eliminate the global variable, and quite possibly fix the GDBusConnection leak (if my guess is right). I'll prototype this for 3.9. I think I've pulled enough D-Bus stunts for one release already. This is due to a race condition in e_client_remove_sync(), this call is made at the end of a test case.. which results in the ESource being removed from the ESourceRegistry server. What happens when the cache-reaper module is loaded, is that the 'test-address-book' source is removed /some time after/ e_client_remove_sync() completes... sometimes this happens right in the middle of the following test case. Probably another side effect of (A). In the interim, it might help if the ESource's unique ID were actually unique for each test case, instead of a static ID for all cases. Instead of test-address-book use test-address-book-N where 'N' is the test case number or some other increasing integer. Matthew Barnes ___ 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] Isolated unit test status report
On Sun, 2013-02-24 at 20:54 -0500, Matthew Barnes wrote: We could try letting EBookClient create its own EDBusAddressBookFactory proxy, call its OpenAddressBook method, and then immediately destroy it. That would simplify the code, eliminate the global variable, and quite possibly fix the GDBusConnection leak (if my guess is right). I'll prototype this for 3.9. I think I've pulled enough D-Bus stunts for one release already. Okay I lied. Prototyped code works fine, it eliminates a good amount of unnecessary complexity and is embarrassingly obvious in hindsight. I went ahead and committed it for 3.8. We'll see if this has any impact on the GDBusConnection leak, but it's an improvement regardless. Matthew Barnes ___ 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] Proposing date for the final 3.6.4 release
On Thu, 2013-02-21 at 20:10 +0100, Milan Crha wrote: Checking GNOME schedule, I propose Wednesday, March 6th, two days after 3.7.91 release. I'd pick the next week, but maybe there will be any things fixed, especially if others would like to see anything in particular being fixed in 3.6.4, which is not yet. Opinions? That date sounds good to me. I'll add it to the wiki. ___ 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] Might be a generic ESourceExtension useful?
On Tue, 2013-02-05 at 08:51 +0100, Milan Crha wrote: After a little discussion with tristan on IRC, not a generic ESourceExtension, but an API added directly to ESource, similar to property API on the old source. Those arbitrary string properties from the old ESource API are precisely what I wanted to AVOID by introducing ESourceExtensions. The point of ESourceExtensions was to: - Break settings into logical groups. - Document what each setting is for, its data type and default value. - Keep common settings consistent in name/type/default across backends. The code duplication in Evolution was meant to be temporary. The long term solution, which I simply haven't had time for yet, is to move all that backend-specific configuration widgetry into E-D-S. But I can make that a priority for 3.10 if we're already talking about regressing back to arbitrary string tables. Matthew Barnes ___ 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] ESourceExtension and backends... claimed generic property ?
On Tue, 2013-02-05 at 17:22 +0900, Tristan Van Berkom wrote: Would it make sense to include some property on the base ESourceExtension class ? For instance, an api such as 'e_source_extension_claim()' could be introduced and called by the consumer of the given extensions. I.e. the file addressbook backend would claim the ESourceBackendSummarySetup extension... clients (those clients which actually created the backend), would then be able to read this claimed property back after creating the addressbook. That seems to me like an awfully obscure corner case to justify adding APIs to the base ESourceExtension class. Maybe I don't understand what problem this is trying to solve. Matthew Barnes ___ 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] ESourceExtension and backends... claimed generic property ?
On Tue, 2013-02-05 at 23:00 +0900, Tristan Van Berkom wrote: I know, we've discussed this already a few months ago, it just seems like something essential to the extension API, you tell the backend to do foo and you just don't know if that backend knows about foo (yet) or not. Seems like that could be mitigated by the backend capabilities property, which -- at least for static capabilities -- should be reachable through the factory APIs and not require an actual backend instance. The static capabilities of a given backend type are the same for all instances of that type, if I'm not mistaken. So it would make sense to be able to query the factory for available backend types and their respective static capabilities prior to instantiating one. ESource and its extensions are meant to be just a dumb data container. It's used for more than just backend configuration. Mail signatures nowadays are ESources with a [Mail Signature] extension, for example, and I'm also considering porting our filter rules and saved searches to use ESource in a similar manner. Matthew Barnes ___ 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] Planning for 3.10
I started a planning page on the wiki for Evolution 3.10. https://live.gnome.org/Evolution/Planning310 Feel free to pile on. The feature list is not binding. It's just to track what we'll have cooking on the stove during the next development cycle. If a feature slips, it slips. Sometimes that's the prudent thing to do. Case in point: My main focus now and going into 3.9 is finishing the WebKit composer. It missed 3.8, unfortunately. Still too many unresolved regressions. Matthew Barnes ___ 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] ESourceExtension and backends... claimed generic property ?
On Wed, 2013-02-06 at 00:47 +0900, Tristan Van Berkom wrote: We should consider adding capability identifiers for recent additions such a ESourceRevisionGuards ESourceBackendSummarySetup. Yes, I agree. ___ 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] ESourceExtension and backends... claimed generic property ?
On Tue, 2013-02-05 at 17:02 +0100, Milan Crha wrote: that sounds new to me, as I recall some exchange plugins did change capabilities based on user preferences. As an example, one could setup GAL browsable in preferences, in which case the capabilities property had been populated with one more item, which let evolution's Contacts view know that it can do initial search, instead of claiming Search for Contacts. I hope it's still doable (I didn't check it), and as such it requires an instance of the EBookBackend descendant. Sure. It makes sense for backends to continue advertising their own capabilities -- static and non-static like browsable. I'm just suggesting a way to peek at a backend's known capabilities ahead of time without having to instantiate it. ___ 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] Regarding API breakage and lost test cases
On Thu, 2013-01-31 at 18:25 +0900, Tristan Van Berkom wrote: I'm not sure what the solution should be exactly, but we should discuss this a bit because the problem space is a little bigger than just the source existing in the client-side before e_source_registry_commit_source_sync() returns. Note that e_source_registry_commit_source_sync() is just a convenience wrapper. If your test cases are just passing scratch sources then what you're actually calling is e_source_registry_create_sources_sync(). That's the function I fixed in bug 685986. So I guess there are 2 potential ways of addressing this problem: There's a 3rd approach. If you want an immediate client connection to a newly created address book, we could have evolution-addressbook-factory create the ESource on your behalf -- since it too has an ESourceRegistry -- and immediately instantiate a backend for it. That would eliminate the race without resorting to client-side hacks. It would require a new method on the addressbook and calendar factory interfaces, but that is easily done now that all our D-Bus interfaces are generated from XML specifications. That was the purpose of my recent rash of commits to master. Just this week I added e_book_client_connect_sync(), which combines the now-deprecated e_book_client_new() and e_client_open_sync() functions into one step. I could enhance this function to detect whether the given ESource is a scratch source, and invoke a different factory method which behaves as described above. No additional client-side APIs required. To summarize: The current addressbook factory D-Bus API looks like this: method name=OpenAddressBook arg name=source_uid direction=in type=s/ arg name=object_path direction=out type=s/ /method It only works for existing ESources already exported by the registry. I'm proposing to add a new method that takes the raw key file content from a scratch ESource in addition to a UID: method name=CreateAddressBook arg name=source_uid direction=in type=s/ arg name=source_data direction=in type=s/ arg name=object_path direction=out type=s/ /method Invoked by passing a scratch source to e_book_client_connect_sync(). The factory method would call e_source_registry_commit_source_sync() on your behalf, and assuming that goes well, return the object path to its newly-created EBookBackend. With equivalent changes to the calendar factory, of course. Matthew Barnes ___ 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] Confusion between EServerSideSource's remote-deletable and removable properties
On Thu, 2013-01-17 at 11:08 +0100, Milan Crha wrote: I'm sorry, but I'm quite confused with the EServerSideSource's remote-deletable and removable properties. They seem to me like they should do the same, mark the ESource with a flag that it can be removed by a user, but they are actually not. Removable is for simply deleting the local key file. This is handled directly by the ESourceRegistryServer. Remote-Deletable is for deleting a remote resource represented by the ESource. It requires the ESource be owned by a collection backend, and only after the remote deletion is successful is the local key file deleted. On the client-side we probably should have separate GtkActions for deleting a local ESource versus permanently deleting a remote resource, so they can at least be labeled differently (e.g. Delete Calendar vs. Delete Remote Calendar) since no one reads warning dialogs. Matt ___ 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] Any experience with GCC code coverage (gcov) for Evolution
On Tue, 2013-01-15 at 17:45 +0100, Paul Menzel wrote: Did anybody ever run this with Evolution? The code coverage option is for use with the E-D-S unit test suite, not for running Evolution. The E-D-S tests currently cover about 2% of the code, or something pathetic like that. Matthew Barnes ___ 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] Redundant type casts in the evolution* code
On Mon, 2013-01-14 at 10:24 +0100, Milan Crha wrote: I noticed some time ago that the code is full of redundant type casts, but I do not understand what it is good for. For better readability, in cases where the type definition also hints at what the callback does. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What happened to email-factory?
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. Matthew Barnes ___ 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] Building Evolution Data Server under GNOME 3.4: GWeather requirements
On Fri, 2013-01-04 at 12:32 +0100, Paul Menzel wrote: Matthew stated that it is a goal to ensure that Evolution Data Server and Evolution build under GNOME 3.4. GWeather does not seem an important component, but it would be nice anyway, if that would build under GNOME 3.4 too so packages scripts do not have to be changed and functionality is on par. Yes, I resisted requiring the new and at the time unstable GWeather API, insisting we support both the old and new GWeather APIs for at least one release cycle. But the requirement got bumped anyway. I let it slide since GWeather is an optional dependency. On GNOME 3.4 you'll have to pass --disable-weather to configure. More details here: https://bugzilla.gnome.org/show_bug.cgi?id=672805 Matthew Barnes ___ 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] [PATCH] shell/e-convert-local-mail.c: Pass correct enum `e_account_find_t` to `e_account_list_find()`
On Thu, 2013-01-03 at 16:15 +0100, Paul Menzel wrote:
Date: Wed, 2 Jan 2013 12:16:50 +0100
Clang 3.2 reports the following warning.
$ clang --version
Debian clang version 3.2-9 (tags/RELEASE_32/final) (based on LLVM 3.2)
$ CC=clang ./autogen.sh
$ make
CC evolution-e-convert-local-mail.o
e-convert-local-mail.c:275:37: warning: implicit conversion from
enumeration type 'enum _e_account_item_t' to different enumeration type
'e_account_find_t' (aka 'enum _e_account_find_t') [-Wconversion]
if (e_account_list_find (accounts, E_ACCOUNT_ID_ADDRESS, id))
{
~~~^~~~
1 warning generated.
You're on your own to patch that.
EAccount and EAccountList classes are gone in 3.6 and later.
Matthew Barnes
___
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] [Evolution] infrastructure
Hi Tom, I'm transferring this topic to the hackers list, so as not to stir up endless discussion on the user list. On Sat, 2012-12-29 at 17:11 +, Tom Davies wrote: At the moment i get the impression that Evolution gets used on a lot more platforms and DE's than just Gnome. That's always been the case but probably more so nowadays, given how fragmented the free desktop space has become. I myself am doing most of my Evolution development on XFCE, using virtualization as needed. Is it technically possible to move the project under a different umbrella? Technically possible, yes. But a HUGE pain in the ass. Especially the bug database. There's at least 12 years of valuable project history in there. I would not want to endure the pain without a compelling reason, and at the moment I see none. Our hosting on gnome.org is a marriage of convenience. Would it make sense to move to The Document Foundation (TDF)? At the moment TDF only have 1 product (LibreOffice (LO)) and all the Board and everything is geared only to that. I dunno, sounds to me like we'd be crashing the party. Without an invitation from TDF, no it would not make sense. Would there be any scope for attracting some of their devs to work on Evo rather than some of them just doing a little bit on LO and then vanishing off into the ether? Not sure I understand the question. I just wondered if anyone here had thought about repositioning Evo strategically? I guess that would first require a strategy? :) I'm in kind of a wait-and-see mode with Evolution's GNOME affiliation given the direction GNOME 3 is going, which has not been to my liking. But afaik Evolution is still welcome on gnome.org. So I'm content to sit tight for now. Matthew Barnes ___ 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] Move backup/restore to evolution-source-registry?
As much as I wish we could be rid of it, many Evolution users still rely on our backup/restore feature for things it was not intended for such as system upgrades. So I'll concede the feature is probably here to stay, at least for the foreseeable future. It seems not only messy but risky for Evolution to be handling backups and restores though. Evolution itself may shut down before initiating the operation, but the E-D-S services remain running the whole time, potentially writing to the directories being backed up or restored. It occurred to me that the backup/restore feature could be made cleaner, safer and more reliable by converting the implementation in Evolution to an evolution-source-registry module and exporting a D-Bus interface for initiating a backup or restore. (The evolution-backup tool would still handle the UI bits, just not do any actual work itself.) When initiating a backup or restore, the registry module could first unexport all data sources, which would effectively shut down all the backends since they'll see it as a source-removed signal. While the backup or restore is running (in-process, not by spawning a separate tool), the registry server could be placed in a busy state such that any subsequent D-Bus method invocations would be denied with a G_IO_ERROR_BUSY response. Meanwhile, the backup/restore module could report progress back to the requesting client. When the backup or restore is finished, the registry server would immediately reboot itself with: e_dbus_server_quit (server, E_DBUS_SERVER_EXIT_RELOAD) instead of depending on the client to tell it to. Does that sound like an improvement over the way it works now? Matthew Barnes ___ 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] Is it worth customizing the IMAP headers to fetch?
On Sat, 2012-12-15 at 13:32 -0500, Matthew Barnes wrote: I'm debating whether or not to support the imap-features Evolution plugin in IMAPX or just throw out the plugin at the same time we throw out the legacy IMAP backend. The plugin currently only works with the legacy IMAP backend. Just to follow up, in the interest of decommissioning the legacy IMAP backend in time for 3.8, I've decided not to support the imap-features plugin in IMAPX. The plugin will be removed along with the legacy IMAP backend, and for the time being we'll continue downloading all headers. Shortening the download time by minimizing the headers is a worthwhile goal, but I think we first need to better utilize server-side searches. I'm already working on server-side BODY searches for IMAPX, but I also think we should utilize server-side HEADER searches. Then the success of a search/filter rule that specifies a particular header is decoupled from the set of headers we choose to cache. (This can be optimized in various ways obviously, but the point is to not _depend_ on our cache for correct results. Let the server do the heavy lifting.) Maybe we can do something along these lines for 3.10... Matthew Barnes ___ 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] Is it worth customizing the IMAP headers to fetch?
On Sat, 2012-12-15 at 19:00 +, David Woodhouse wrote: The interesting use case, perhaps, is the first run of Evolution on a new mail store. That's when the full vs. targeted header fetch is going to be most noticeable. Right, and since we don't even present these IMAP header options in the account setup wizard, the user doesn't even have a chance to monkey with them until the initial fetch begins. You have to wander back into the account settings to see that page, and by then your headers are probably all fetched. But even if we conclude that the more specific fetch is worthwhile, I'm still not convinced that a separate UI for *choosing* those headers is at all sane. If the user sets up filters which *look* at a given header, then we damn well ought to fetch that header automatically. The user shouldn't be forced to go and find a separate plugin to make their filter actually work. Or do I misunderstand how this works? No you're right, I think that's the sole purpose of the Custom Headers section. What I'm taking away is there may be value in fetching specific headers, but not in it's present form. So I'm inclined to drop the plugin, but leave open the possibility of doing this kind of thing more smartly behind the scenes. Thanks for the feedback. Matthew Barnes ___ 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] mail migration
On Fri, 2012-12-14 at 04:54 +0100, Sasa Ostrouska wrote: I have about 5Gb of e-mails on my laptop which I use for work, and it is still on evolution 2.26.3. I would like to migrate now this stuff to evolution 3.6.x What is the best way to do that ? Hi Sasa, While Evolution does try to automatically migrate data when necessary after upgrading, this is intended more for incremental upgrades, say from 3.4 to 3.6. Automatic data migration becomes less tested and therefore more risky the more versions you skip. Going from 2.26 to 3.6 is a huge leap! I recommend breaking the upgrade into at least two steps, particularly 2.26 - 3.0 - 3.6. Evolution 3.0 was the first version to convert your local mail from mbox format to Maildir format. Do that first, and once you verify your local mail is in tact, proceed to 3.6. Evolution 3.6 was the first version to convert your account info from GConf entries to plaintext data files. Account info is now stored in ~/.config/evolution/sources where it's much easier to backup and copy. The contents of this directory determine whether Evolution runs the account wizard on startup. Matthew Barnes ___ 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] Evolution library consolidation
On Thu, 2012-12-13 at 08:59 +0100, Milan Crha wrote: I didn't understand from the initial announcement that you'll not only merge those above in one .so, but that you'll also move all the files into one folder. This makes it quite messy to find anything, the previous file layout was better from my point of view. I guess making eutil/menus eutil/table ... as static libraries, linked into one libeutil.so would work pretty well too, with an advantage of sorted code. The old partitioning is still reflected in the API documentation. I don't see anything messy about having the source files in a flat list. GTK+ is able to manage its widgets well enough with a similar layout. Matt ___ 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] Evolution library consolidation
On Sun, 2012-12-09 at 08:59 -0500, Matthew Barnes wrote: I expect this is a couple days worth of monkey work, but I should have it done by mid-week in time for the 3.7.3 release. Just committed this to master. If you're building from git, I would strongly advise blowing away your current installation and rebuilding all Evolution-related modules from scratch to avoid interference from now-defunct libraries. Also check out the new libeutil API documentation. I'm still populating the libeutil-sections.txt file but I hope to complete it by month's end. Matthew Barnes ___ 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] Evolution library consolidation
On Tue, 2012-11-27 at 14:20 -0500, Matthew Barnes wrote: Immediately after the merge I'm going to consolidate Evolution's base libraries into a single base utility library. libeutil seems as good a name as anything else I can think of, so I'm going to stick with that. Since the webkit-composer branch is not quite as ready to merge as I thought, and I'd like to get the library consolidation done before it gets any later in the development cycle, I'm going to proceed with it now and I'll just adapt Dan's branch to the changes myself. I expect this is a couple days worth of monkey work, but I should have it done by mid-week in time for the 3.7.3 release. Matthew Barnes ___ 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 library consolidation
I'm currently smoke testing Dan's webkit-composer branch before giving him the go-ahead to merge it to master. Immediately after the merge I'm going to consolidate Evolution's base libraries into a single base utility library. libeutil seems as good a name as anything else I can think of, so I'm going to stick with that. I'm also going to absorb libedataserverui back into Evolution, since Evolution is now the only module using it (I've done my due diligence on other modules that still show a dependency -- in most cases it was just a historical artifact that could be dropped). So all the non-deprecated APIs in libedataserverui will become part of Evolution's new libeutil. I plan to have this in for Evolution 3.7.3. The new libeutil will include APIs that are currently scattered across: a11y/libevolution-a11y.so e-util/libeutil.so filter/libfilter.so widgets/e-timezone-dialog/libetimezonedialog.so widgets/editor/libeeditor.so (new in Dan's branch) widgets/menus/libmenus.so widgets/table/libetable.so widgets/text/libetext.so libedataserverui/libedataserverui.so (from E-D-S) At least, that's the list for starters. I'd still like to keep things like libemformat.so, libcomposer.so and libeshell.so separate. I'm on the fence about the smime libraries. Additionally, since almost all the #include paths will need updating anyway, I'm going to move libeutil to a single-include model like we've done for Camel and E-D-S. In addition to convenience, it helps shield 3rd party apps as well as our own extension packages from quite so much API churn, even though we still make no guarantees about API stability in Evolution libraries. The new #include directive for libeutil will be #include libeutil/libeutil.h which will bring in all headers in the library. With all the base utility libraries under one header, maybe we can then get serious about producing some good API documentation for this stuff. My attempts thus far have been half-hearted at best. Matthew Barnes ___ 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] Evolution slowing down
On Tue, 2012-11-27 at 18:59 +, Karl Relton wrote: Is it just me, or is evolution 3.6 now really slow. I find opening and closing message windows markedly slower than 3.2 on the same hardware. Probably just you, since I've not seen any such slowdown. If anything, rendering is much faster now with the move to WebKit. One possibility is your mail summary database has accumulated a lot of cruft and needs garbage collected. Unfortunately we don't yet run this automatically so it has to be done manually. Eventually I'd like to tie it into Folder - Expunge and File - Empty Trash. Shutdown Evolution and try running this little script: http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb Matthew Barnes ___ 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] Evolution library consolidation
On Tue, 2012-11-27 at 14:20 -0500, Matthew Barnes wrote: The new libeutil will include APIs that are currently scattered across: a11y/libevolution-a11y.so e-util/libeutil.so filter/libfilter.so widgets/e-timezone-dialog/libetimezonedialog.so widgets/editor/libeeditor.so (new in Dan's branch) widgets/menus/libmenus.so widgets/table/libetable.so widgets/text/libetext.so libedataserverui/libedataserverui.so (from E-D-S) Addendum: Forgot to list an obvious and important one: widgets/misc/libemiscwidgets.so ___ 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] UI interaction from book/calendar backends
Yes, the gtk_init() issue occurred to me after posting that suggestion. I agree a separate process is the better idea. Then gtk3 won't taint evolution-source-registry. (Apologies for top-posting. I'm trying out Dan's webkit-composer branch and it seems to have some kinks yet to be worked out, especially in quoted replies.) Matt On Mon, 2012-11-26 at 08:37 +0100, Milan Crha wrote: On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote: 1) Write this as a ESourceRegistryServer extension, and just link to GTK+ from the extension module. That way it's easily removable if the Tizen folks don't want it, or they want to implement their own version using Qt. Hi, I was thinking of it, and I feel like it's not correct to initialize gtk within an extension, thus this should be just a new server within eds, with its default implementation using gtk3, which will be accessed through DBus (as you suggested), thus will be replaceable by other implementations. Bye, Milan ___ 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 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] Drop or limit ChangeLog files in tarball releases?
On Thu, 2012-11-22 at 08:52 +0100, Milan Crha wrote: I'm only waiting for an opinion from Matthew, then I'll happily change the build script. I guess I don't have a strong attachment to it. ChangeLog files are technically part of the GNU Coding Standards [1], and strictly speaking the product we ship is our tarball releases, not our version control system, so there's an argument to be made that we should ship a complete log of changes in our product updates. That said, the GNU Coding Standards were written in an age before distributed version control, and its relevance is debatable nowadays. And I agree 'git log' is more practical for researching change history. We could limit the log to changes since the last major release (3.6.0 currently, then start clean after 3.8.0 ships) to keep the file size under control, but if you'd strongly prefer dropping it entirely then I won't complain. Also, just for the record, the script snippet I'm using to generate the ChangeLog file comes from https://live.gnome.org/Git/ChangeLog. Matt [1] http://www.gnu.org/prep/standards/html_node/Change-Logs.html ___ 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] [evolution-kolab] using a TPM for SSL/TLS client certs, reloaded
On Tue, 2012-11-13 at 11:18 +0100, Christian Hilberg wrote: My question now (for documenting the status quo) is whether anyone is currently working on getting certificate-based client authentication utilizing a TPM flying in Evolution for OpenLDAP+GnuTLS at present or whether there are any plans to support this use case in the near future. No one is working on it at the moment, and I don't see it being supported in the near future without sufficient demand or external contributors. I can't speak for Milan, but for me it's more ignorance in this area than objection or lack of interest. I will say that I'd like to see Evolution (Camel in particular) stop talking directly to NSS and defer certificate management to the various security libraries and APIs in the GNOME platform -- p11-kit, libgck, GTlsCertificate in libgio, etc. We haven't even begun to utilize these libraries yet (except perhaps through libsoup), and I sense there's a lot of redundancy in our code that could be eliminated by doing so, not to mention automatically gaining more consistent and probably improved behavior. But not yet being very familiar with these libraries, at present I can only make hand-wavy motions in their general direction. I'm hoping next year we can start taking real steps in that direction. That's the best answer I can offer for now. In the meantime, maybe consider using a Virtual Private Network. ;) Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What do I need to add/enable/remove re @GNOME_CODE_COVERAGE_RULES@ so that compilation will not stop on 'Makefile:1097: *** missing separator. Stop.'
On Fri, 2012-11-02 at 14:12 +, Reid Thompson wrote: When compiling from current head, compilation stops on reaching @GNOME_CODE_COVERAGE_RULES@ You need a more recent gnome-common. 3.6 or later. ___ 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] Regarding ESource and ESourceExtension
On Mon, 2012-10-08 at 18:40 +0900, Tristan Van Berkom wrote: Is it intended that the frontend must know what extensions are supported by a given backend ? What extensions are you worried about, specifically? And what's the use case for configuring them by hand? This page explains which extensions are typically present in a given type of key file: https://live.gnome.org/Evolution/ESourceFileFormat The various config modules in Evolution [1] serve as configuration backends for the account editor and the New Address Book and New Calendar dialogs. Each module knows what extensions are supported by its respective Camel/E-D-S backend. Matthew Barnes [1] http://git.gnome.org/browse/evolution/tree/modules ___ 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] Regarding ESource and ESourceExtension
On Mon, 2012-10-08 at 23:56 +0900, Tristan Van Berkom wrote: More specifically, I was under the impression that the ESourceExtensions were (at least partially) for the purpose of, well, extending the work flow and configurations provided by given backends. Backend-specific settings live in a dedicated extension class for that backend. The key file groups are typically named [$FOO Backend]. You can probably grep your own ~/.config/evolution/sources directory for examples if you're running Evolution 3.6.0. Not all backends currently have their own dedicated extension class. I've been adding them as needed. The local address book backend does not yet, but the local calendar backend does: http://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/file/e-source-local.h So we would add a similar class for the local address book backend to hold the photo settings you mentioned. (Some name juggling may have to take place, since I unfortunately named the local calendar extension merely Local Backend instead of Local Calendar Backend.) Also worth noting is backends don't utilize all available extensions. Some extensions are only used to hold settings for client-side features, and are disregarded by backends. Some examples: ESourceAlarms -- [Alarms] Apart from the configuration UI, this extension is used only by evolution-alarm-notify to determine whether to show notifications for a particular calendar and to record the timestamp of the most recent notification for that calendar. ESourceAutocomplete -- [Autocomplete] Apart from the configuration UI, this extension is used only by the ENameSelectorEntry widget to decide whether to query a particular address book when attempting to complete a partial email address. This widget is used in the To/Cc/Bcc fields of Evolution's email composer. Another example -- for 3.8 I'd like to introduce per-account new mail notification options for Evolution by moving the options currently under Edit - Plugins - Mail Notification to the Account Editor window. This will involve introducing a new ESourceNotification extension, which mail backends would disregard since Evolution itself handles notifications. Now our configuration UI story is a bit awkward at the moment because the backend-specific config modules I mentioned previously live in Evolution. But because the backend-specific ESourceExtension classes are not included in libedataserver's public API (that's intentional), those classes have to be duplicated in Evolution. In the case of the local calendar backend extension I pointed out above, that same code also lives in Evolution's cal-config-local module: http://git.gnome.org/browse/evolution/tree/modules/cal-config-local/e-source-local.h Obviously this code duplication is suboptimal, but at least there exists a formal settings API now, whereas under the old GConf XML system it was just an ad-hoc string dictionary. I plan to address the code duplication issue by eventually moving the whole configuration UI framework and all the config modules down to Evolution-Data-Server. Then at least the config UI modules and the backend modules can live together and share the extension classes. Not sure if this fully addresses your question or not. I'm still at a bit of loss as to your use case. Matthew Barnes ___ 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] Regarding API breakage and lost test cases
On Tue, 2012-10-02 at 20:35 +0900, Tristan Van Berkom wrote: Ah, this is gold. I'll be able to readjust things with this. I've added a new section to the migration guide which covers the basics of creating a new local address book or calendar: https://live.gnome.org/Evolution/ESourceMigrationGuide#How_do_I_create_a_new_calendar_or_address_book.3F Hope this helps, Matthew Barnes ___ 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] Regarding API breakage and lost test cases
On Fri, 2012-10-05 at 22:19 +0900, Tristan Van Berkom wrote: a.) e_source_registry_commit_source_sync() seems not exactly very sync. I haven't looked into that in detail but surely the registry server needs to block on something else before sending the reply. The issue is on the client side in ESourceRegistry. I had some pretty nasty code at one time to deal with this but must have yanked it while reworking the APIs. Even after the remote method call completes, ESourceRegistry will still have to stop and wait for an object-added signal from its internal GDBusObjectManagerClient, which is running in its own isolated thread. The object-added signal has the new GDBusObject needed to build the new ESource instance. And it can't complete on just any object-added signal -- it has to be the object-added signal corresponding to the scratch ESource that was just submitted. I'll see if I can restore that nastiness again in 3.7.x. However, the e-source-registry user facing APIs seem to make an attempt at doing this internally (i.e. it has it's own thread and mainloop presumably intended to handle the dbus messages as a convenience to the caller), so... probably just a minor detail or bug to fix there... The GDBusObjectManagerClient only emits signals from the GMainContext that was the thread-default at creation time. So it's created in its own dedicated thread to ensure its signal emissions cannot be inhibited by something pushing a different thread-default GMainContext. Otherwise deadlocks occur when an ESourceRegistry method has to stop and wait for a signal emission from the GDBusObjectManagerClient, such as in the case described above. Matthew Barnes ___ 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] Master branch is now 3.7.1
On Mon, 2012-09-17 at 12:18 +0200, Christian Hilberg wrote: Matt, I guess it'll be you pushing 3.6.0 out the door, right? (It's just a matter of when to expect 3.6.0 to be out so I can wrap up evolution-kolab for that release). Yes, I'll handle 3.6.0 next weekend. See: https://live.gnome.org/ThreePointFive Matt ___ 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] Master branch is now 3.7.1
I released Evolution 3.5.92 and co. over the weekend and created gnome-3-6 branches for the following modules: gtkhtml evolution evolution-data-server evolution-ews So 3.7 development is now open on these modules. Evolution 3.6.0 and co. will be released from the gnome-3-6 branch. I defer to Milan and Christian to branch evo-mapi and evo-kolab respectively when they're ready. Just a reminder that Milan and I will both be taking personal time off for the rest of the month starting this week. I'll still be somewhat reachable on IRC this Monday and Tuesday but won't be on the clock, and thereafter reachable by email only until Monday, October 8th. Matthew Barnes ___ 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] Evolution 3.8 Planning
On Wed, 2012-09-05 at 09:57 +0200, Christian Hilberg wrote: Thanks for the heads-up. I remember you mention some sort of API restructuring / rework concerning E-D-S, D-Bus and EClients you had in mind for 3.7/3.8 cycle. Do you have anything cooking in this regard already? Might be worth putting on that page. My plan is to write XML interface specifications for all our calendar and address book D-Bus interfaces, use gdbus-codegen to generate the GDBus classes, and throw away our old egdbus libraries. I've already made some progress on this. We're currently using gdbus-codegen to generate the GDBus classes for the evolution-source-registry service. It's a fantastic tool and the XML interface specs are much easier to maintain and extend. As I recall, the current D-Bus classes in our internal egdbus libraries were generated once by some now-unsupported and non-working precursor to gdbus-codegen, so we've been stuck hand-maintaining the generated C code. That makes any D-Bus interface changes we wish to make (such as adding a synchronize method) a royal PITA. While I'm at it I'll be deprecating some parts of the EClient APIs whose function signatures imply they're non-blocking but in fact make blocking D-Bus calls, and replacing them with proper cancellable synchronous and asynchronous functions. I'll try my best to NOT break the libebook and libecal APIs. Not yet sure of the impact to backend APIs, I'll know better shortly. Since I'm hoping to wrap this up in time for 3.7.1 and it's really just a cleanup operation, I'm not sure if it's worth listing on the planning page. If the scope of this project balloons too much I may reconsider. Matt ___ 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] evo 3.5.91 git head doesn't appear to be storing/
On Wed, 2012-08-29 at 16:11 +, Reid Thompson wrote: (evolution-calendar-factory:8178): GLib-GIO-WARNING **: Can't find module 'dconf' specified in GSETTINGS_BACKEND GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. Installing dconf to the same prefix as glib does the trick for me. Matt ___ 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] recent change breaks filters???
On Fri, 2012-08-17 at 08:31 +0200, Milan Crha wrote: ews account name +-- Foreign Folders +-- Mailbox - someone else +-- some subscribed folder +-- Favourites (Public Folders) +-- Mailbox - User Name I was suggesting to have separate top-level nodes: ews_account_name +-- Inbox +-- Drafts +-- Deleted Items ews_account_name (Someone Else) +-- Some Subscribed Folder ews_account_name (Public Folders) +-- Some Subscribed Folder Then these could be enabled/disabled and ordered independently in the folder tree. The user could keep them all together or move the shared folders to the bottom of the folder tree to get them out of the way if they're only needed occasionally. Internally you could maybe structure the ESources as collections within a collection: Collection for User Name +-- Calendar +-- Contacts +-- Collection for Someone Else +-- Collection for Public Folders We might have to rework some internals to make this display as we want, but this is the sort of thing I had in mind in making ESources a free- form hierarchy. Matt ___ 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] recent change breaks filters???
On Thu, 2012-08-16 at 13:36 +, Reid Thompson wrote: are the accounts under ~/.local/share/evolution/mail only used for local mail, or locally sync'd mail? Those directories are for local mail storage, correct. and the .cache/evolution accounts are used for 'everyday' operations for remote mail? Those directories are for caching remote mail, correct. The accounts themselves are in ~/.config/evolution/sources now. Matthew Barnes ___ 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] recent change breaks filters???
On Thu, 2012-08-16 at 15:12 +, Reid Thompson wrote: Thanks, so it appears I just need to update filters.xml to convert all instances of the folder uri substring folder://1321906405.19378.1%40raker2/Inbox/ to folder://1321906405.19378.1%40raker2/Mailbox%20-%20Reid%20Thompson/Inbox/ Yep, sounds right. Don't know how that happened. $ cat 1321906405.19378.1@raker2.source [Data Source] DisplayName=Reid.Thompson@ateb.comEWS Enabled=true Parent=1339189036.14925.13@raker2 [Mail Account] IdentityUid=1339189036.14925.11@raker2 BackendName=ews [Refresh] Enabled=true IntervalMinutes=3 [Message Disposition Notifications] ResponsePolicy=never which lists parent as 1339189036.14925.13@raker2 and account as 1339189036.14925.11@raker2 -- but all of the filters fail with No such folder:... messages Those files just describe the account itself, not your mail folders. Matthew Barnes ___ 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] recent change breaks filters???
On Thu, 2012-08-16 at 16:02 +, Reid Thompson wrote: filters will work manually, but they're not getting automatically ran. Any suggestions? Filters log shows no activity as emails come in. applying filter manually works and gets logged. Check your account settings first: [ ] Apply filters to new messages in Inbox on this server Maybe the backend is confused as to which folder is now Inbox. Does your Inbox folder show an Inbox icon in the folder tree? Matthew Barnes ___ 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] recent change breaks filters???
On Thu, 2012-08-16 at 19:04 +0200, Milan Crha wrote: ouch, I did that, I didn't think of filters at all :( The reason for movement to Mailbox - User Name is to be able to add folders of other users to the ews. They will then show in Foreign Folders/Mailbox - other user/..., but it seems I broke with the hierarchy change too much. I'm sorry for that. The change is harmless for EWS itself, as it uses folder IDs, whose didn't change, but I forgot of filters. Probably would be better to set up a separate collection for another user's folders, rather than try to cram it all into one collection. You could still use the authentication details for the primary account, but just indicate a different mailbox in the collection source. Matt ___ 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] Some minor Camel API breaks
Just for the record, I made a few API changes to Camel over the weekend. The changes help increase Camel's thread-safety. One lesson I learned during the account-mgmt work is when returning a pointer to a reference counted object in a multi-threaded environment, it's better to return a new reference to the object which the caller must release. Otherwise it introduces potential races where the object might be finalized while the caller is still using it, or before the caller has a chance to reference it for safe keeping. Camel gets this wrong almost everywhere. Here's what I changed: * camel_session_add_service() now returns a new reference to the newly added CamelService. The caller must call g_object_unref() on it. * camel_session_list_services() now returns a list of new references to available CamelServices. The caller must call g_object_unref() on each list element before freeing the list. * camel_session_get_service() is now camel_session_ref_service() and returns a new reference to a CamelService. The caller must call g_object_unref() on it. * Similarly for camel_session_get_service_by_url(). * camel_service_get_settings() is now camel_service_ref_settings() and returns a new reference to a CamelSettings. The caller must call g_object_unref() on it. There's more to be done along these lines but that's all I had in me for one weekend. In particular, I still want to rename CamelStore's get_folder() method to ref_folder() to better reflect its current behavior and since I can never remember the ownership transfer on that method. But that might have to wait until 3.7. Also some miscellaneous changes: * Realized CamelSession's forward_to() method blocks and needs to be asynchronous, so I GIO'ized it with the usual sync+async pattern. EMailSession was hacking around this by spawning an async operation from within its forward_to() method and then immediately returning TRUE as if the whole forward_to() operation were successful. So it lies, basically. * Killed camel_session_lock/unlock(). Exposing mutexes in a public API is just evil and indicates a bad design. There's still a few more of these to kill off. 3.7 material, perhaps. Matt ___ 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] Some minor Camel API breaks
On Mon, 2012-08-13 at 19:00 +0100, Philip Withnall wrote: This is all great work! Just a point to note: Telepathy uses the convention of calling refcounting getters ‘_dup_’ (e.g. “camel_session_dup_service()”) rather than ‘_ref_’. This seems better (imo) because ‘ref’ could get confused with a reference-count-increasing function which _doesn’t_ return the reference. If it’s not too late, perhaps Camel could be changed to use this ‘_dup_’ convention instead? I actually like 'ref' better and am already using it throughout the new ESource APIs in Evolution-Data-Server. The lack of consistency across libraries is a little annoying, but I find this convention easiest to remember: * foo_get_bar() You don't own the returned bar and can safely nest the function call without leaking resources. These functions may not be thread-safe, however. * foo_dup_bar() You own an allocated copy of bar and will generally call something like bar_free() to release it. These functions should always be thread-safe. * foo_ref_bar() You own a new reference on bar and will generally call something like bar_unref() to release it. These functions should always be thread-safe. * foo_ref() This is a self-referencing function. You own a new reference on foo and will generally call something like foo_unref() to release it. In all cases I can think of, the function also acts as a pass-through by returning the input value. These functions are usually thread-safe by way of atomic integer ops. I think the last two nicely sidestep the confusion over ref. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
