Re: [Evolution-hackers] [evolution-kolab] Version 0.30.0 released, moved to gnome.org
On Tue, 2011-11-08 at 15:44 +0100, Christian Hilberg wrote: > With this release, active development has been moved away from SourceForge and > under the hood of the GNOME project. Thanks to everyone helping with the > migration and thanks for the warm welcome at gnome.org. Welcome aboard! ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Can I remove some old migration cruft, pretty please?
On Mon, 2011-11-07 at 16:21 -0500, Matthew Barnes wrote: > Would anyone object to me removing the migration code from the old mail > summary files to SQLite? Believe it or not it's been three years since > we started using SQLite back in Evolution 2.24. It's done. http://git.gnome.org/browse/evolution/commit/?id=12fab9c6a622398e40515ab8c8e8f2efd790fcd8 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Camel no longer depends on libedataserver
I have severed all of Camel's remaining dependencies on libedataserver, mostly by way of code duplication. In particular, all of Camel's search and filtering code now uses CamelSExp, which is a clone of ESExp. libcamel now builds first in the evolution-data-server module, and its pkg-config file has shed its libedataserver-1.2 requirement. You should consider it a base library for E-D-S, like libsoup or libgdata. There is no longer any _technical_ reason why Camel needs to be bundled in the evolution-data-server module. I DO intend to split Camel off at some point, but not yet. Parts of its API are still a complete mess and I'd like to give them some attention and also reach some semblance of API stability for the library as a whole. We're not there yet. Clean rebuilds are necessary, of course, but beyond that no one should notice any difference. If you find a need for libedataserver to link to Camel in 3.3, feel free. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel no longer depends on libedataserver
On Mon, 2011-11-14 at 23:33 -0500, Matthew Barnes wrote: > There is no longer any _technical_ reason why Camel needs to be bundled > in the evolution-data-server module. I DO intend to split Camel off at > some point, but not yet. Parts of its API are still a complete mess and > I'd like to give them some attention and also reach some semblance of > API stability for the library as a whole. We're not there yet. Chen asked me in the IRC meeting today [1] to clarify my position on splitting off Camel. My vision for Camel is simply for it to be a nicely crafted, reusable, well-documented mail client library with tight GIO integration. I do believe that's in line with what it was intended for all along. But as long as it stays arbitrarily bundled in E-D-S it's not really reusable. Any project looking to use such a library would be scared away by having to drag in E-D-S for no reason. And I want Camel to be a viable choice. [2] Picking up just one additional user besides Evolution, like perhaps something from the XFCE or LXDE projects, would be really healthy for Camel. It would demonstrate that Camel _is_ reusable. It would force us to consider other users of Camel before making changes. That's a good thing. It's a sign of library maturity. Camel is a base library for E-D-S. Always has been, for as long as I've been around anyway. We already treat it as a base library. Splitting Camel out of the E-D-S git repo would have minimal impact. In concrete terms, it would involve moving the "camel" source directory, its API docs, and some autoconf goo to a separate git repo. Then we would start releasing Camel tarballs. That's it. Aside from maybe some pkg-config tweaks there would be ZERO impact to Evolution or the extension modules. [It occurred to me that we would first need to give Camel the ability to load provider modules from both built-in and custom directories, so the evo-specific providers stay evo-specific. IMAPX, POP, SMTP, etc. would move perhaps to /usr/lib/camel/providers; but MAPI, EWS, GroupWise, etc. would stay where they are. Perhaps that's where the resistance is coming from? That's an easy fix.] Let me emphasize again that Camel is not yet ready to be split off from E-D-S. This is a long term goal, and in fact I've been nudging Camel in this direction for years. Porting Camel to GObject, sealing up object structures, moving to a single-include paradigm like GTK+ did, adding an asynchronous API, keeping its API docs up-to-date, and now severing its libedataserver dependency... all done in the service of molding Camel into a standalone GLib-based mail library. I think an actual split is probably a year or two out yet, at least. Splitting off Camel now would create API stability expectations that I'm not ready to meet. Parts of Camel's API still need a lot of love, and sheltering the library in the E-D-S repo for the time being gives us cover to break the API to fix it, until everything is hammered into shape and nicely polished. Camel is still "in the shop", so to speak. I view the split as just a logical step in Camel's path to maturity, so I was a bit taken aback by the resistance expressed. Hopefully I've now clarified myself. Matthew Barnes [1] http://projects.gnome.org/evolution/meeting-logs/2011-11-16.shtml [2] Some distros like Debian already package Camel as a standalone library. "apt-get install libcamel-1.2-23" Perhaps the point to all my rambling is it should be packaged this way UPSTREAM too. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] wip/settings branch is merged
The "wip/gsettings" branch has been merged to master for Evolution 3.3.3. This branch migrates most of our simple GConf keys (strings / integers / booleans) to GSettings. Huge thanks to Rodrigo Moya for his work on this! After installing the updated code (which includes a .convert file), I believe you can manually run "gsettings-data-convert" to migrate your data from GConf to GSettings. At least according to the documentation; I've not tried it myself yet. Otherwise Evolution will start with most settings reset to defaults. Normally "gsettings-data-convert" gets run as an auto-start program when you log into your desktop session, but I figure we probably all have our own local Evolution installs. GSettings is not very forgiving of typos and likes to abort in lieu of polluting its API with GErrors. I think I tracked down all the typos already, but be on the lookout in Evolution's more remote corners. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] wip/settings branch is merged
On Wed, 2011-11-23 at 16:05 +0530, Srinivasa Ragavan wrote: > I rebased email-factory-3-4 branch of evolution on top of gsettings > merge. I'm away for a week in Finland, hopefully you get time to merge > this around :-) Okay, thanks. I'll be traveling too for the next couple weeks. Working off and on, won't be on IRC much. But I'll try to look at this next. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] When to release 3.2.3?
On Thu, 2012-01-05 at 14:30 +0100, Milan Crha wrote: > I feel it's a good time to release final 3.2.3, because the 3.2.2 had > been released on 2011-11-14 which is quite long time ago. The 3.3.4 is > scheduled on January 16th, thus what about doing the 3.2.3 release > the next week, say on January 11th or so? > > Any ideas/concerns/proposals/agreements/todos? How bout January 9th, since we usually release tarballs on Mondays? According to [1] I was already up for the next release, so I've penciled in 3.2.3 for me and flip-flopped the subsequent releases with Chen. Matt [1] http://live.gnome.org/Evolution/ReleaseHOWTO ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Vacuum folders.db on expunge?
I still find myself occasionally pointing users to the little shell script Srini wrote some years ago to vacuum out all your folders.db. Since moving to XDG base dirs I've kept an updated version of it here: http://mbarnes.fedorapeople.org/evolution-rebuild-summarydb Usually after running the script, users report that Evolution feels fast and responsive again. Evolution really needs to be doing this on its own periodically, but I would rather the user not be aware of it. So no new pop-up dialogs or info bars or anything like that. I thought a natural place to tie a database cleansing into would be a folder expunge (and also File -> Empty Trash), something most users do every now and then already -- or at least something we could instruct them to do directly within Evolution. Plus, users are already accustomed to a short delay when emptying trash, so a little extra delay there should be pretty inconspicuous. Thoughts? Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Nitpick for a mailing list admin
Akhil, are you still a mailing list administrator? The subscribe pages on mail.gnome.org list you and "pg...@novell.com" but I don't know who that is. Anyway, I noticed a typo on the evolution-list description [1]: "General discussion and user queries of the Evolution" We need to remove the word "the": "General discussion and user queries of Evolution" But it brings up the larger point of who's managing our mailing lists these days and can Chen and I get in on that so we have a bus factor >1? Matt [1] http://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] hopefully minor help on building for 3.3.4 em-format-html.c:1583: undefined reference to `camel_operation_cancel_check'
On Fri, 2012-01-20 at 17:24 +, Reid Thompson wrote: > Attempting to update to 3.3.4 from gnome-3-2 using the sources below. > I'm currently getting the build error noted at bottom. Do I need to > bump one of the other components up, or am I missing a component? 'camel_operation_cancel' and 'camel_operation_cancel_check' were removed from E-D-S in some earlier 3.3.x release. My guess is your evolution git repo is littered with build artifacts from 3.2 and 3.3, probably from switching branches in-place. I suggest running "git clean -xfd" and rebuild Evolution 3.3.4 from scratch. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] IMAPX code dependency
On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote: > I need to replicate some code paths of IMAPX (e.g. all paths that > lead from the Store to imapx_untagged, so I can extend this one > for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX > code duplication I cannot avoid at present. > > This means that for every (major) change in upstream IMAPX, > I need to pull the changes in and check whether I need to > fix something in my code dupes. Would it help you much to turn imapx_untagged() and similar functions into virtual class methods in CamelIMAPXServerClass? Then you could override the method in your subclass, and have it chain up first and then do other custom stuff. Or does the logic not allow you to break things out that cleanly at present? (wouldn't surprise me) Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution-data-server offline handling
On Fri, 2012-02-03 at 11:38 +0100, Alexander Larsson wrote: > IMHO we should implement actual network availibility tracking in > EDataFactory (using NM or ConnMan) to get the real state inside the > backends (i.e. if there is no network the backends should always be > offline). Alex and I talked this over on IRC. Summarizing the plan forward here for the record. I had already been salivating over the new GNetworkMonitor API in GLib 2.31, but hadn't intended to use it until the 3.5 cycle. It means we can kill the network-manager/connman/windows-sens network detection modules in Evolution and rely only on GIO from now on. (Finally!) But since the situation is so dire for GNOME Contacts, we're going to utilize GNetworkMonitor in Evolution-Data-Server for 3.4, but only if linking to GLib 2.31. Alex will supply patches. Our minimum GLib requirement will remain GLib 2.30 for GNOME 3.4. > The question remains however what to do about the forced offline > state. If you put evolution in forced offline mode, do you truly want > to turn the desktop-global addressbooks and calendard into offline > mode too? It might be pretty suprising that suddenly the contacts and > calendar integration in the shell and contacts is readonly because you > switched your mailer to offline mode. It can be especially problematic > if you then close evolution, and have no other place to disable > offline mode. > > Maybe we should make the "offline" mode in evolution really only > affect the camel_session online state? I don't know exactly what the > usecase is for the evolution offline mode, so I don't know what the > best approach is here. I agree with this. Evolution's forced offline state should only affect Evolution, not E-D-S backends. So that means, at least while mail is still handled by Evolution, forced offline state only applies to mail. This is consistent with making Evolution "just another E-D-S client" and not having special privileges over those desktop services. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution-data-server offline handling
On Fri, 2012-02-03 at 21:27 +, Philip Withnall wrote: > This sounds good. Do I have to make any fixes to the Google Contacts > address book backend, or will it all be handled centrally? (i.e. With > this GNetworkMonitor change, will there be any bugs left in the Google > backend’s handling of online/offline status?) The EBackend base class already has an "online" boolean property. Backend modules just have to honor it. For 3.4 we can just bind it to GNetworkMonitor:network-available if linking to GLib >= 2.31. For 3.6 I'd like to have each EBackend manage its own "online" state by calling g_network_monitor_can_reach() in response to "network-changed" signals from GNetworkMonitor. Then we get VPN awareness for free! In either case it's all handled in the base class. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libemail library installation
On Mon, 2012-02-06 at 12:55 +0100, Milan Crha wrote: > I just realized that libemail-engine and libemail-utils libraries are > installed into $PREFIX/lib, while any other evolution libraries are > installed into $PREFIX/lib/evolution//... > > Is the change with libemail done on purpose or just a mistake? Good catch. I think they should stay in $PREFIX/lib/evolution/ until we start versioning them properly. Not sure we're ready for that. At minimum those APIs need to be fully documented for Gtk-Doc first. But since they're bound for Evolution-Data-Server, ultimately they belong alongside libecal and libebook in $PREFIX/lib. ** Note libemail-utils won't be around very long and might not even make it to E-D-S. It's entirely made up of APIs that are either deprecated or that I want to eventually kill (mail-mt.c). Srini and I discussed this and he's on board with it. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libemail library installation
On Mon, 2012-02-06 at 09:21 -0500, Matthew Barnes wrote: > Good catch. I think they should stay in $PREFIX/lib/evolution/ > until we start versioning them properly. Not sure we're ready for that. > At minimum those APIs need to be fully documented for Gtk-Doc first. FYI, I have corrected the install paths and updated the pkg-config files for these libraries in the following commits: http://git.gnome.org/browse/evolution/commit/?id=1550b303d8d65b885addcafa314dfcbe1769ac78 http://git.gnome.org/browse/evolution/commit/?id=f2e87c8741419c4cabb44563ab186065f7bf528a Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Home news from the Evo/WebKit Universe
On Thu, 2012-02-09 at 12:12 +0100, Dan Vratil wrote: > just a short note - thanks to Milan who has decied to dig into WebKit, > embedding widgets into WebKit webview works again. That's awesome news! I think I suffered that same bug early on in the branch. Nearly drove myself crazy trying to get a simple embedded icon to draw. Well done to both of you! Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution community meeting at #evolution-meet channel - Feb 15 - 3:30 PM UTC
On Tue, 2012-02-14 at 17:03 +0530, Chenthill wrote: > Hi, > The meeting goes as follows, > > * Project updates > * Discussion on queries/decisions > * Individual updates > > http://live.gnome.org/Evolution/CommunityMeet I won't be able to make the meeting tomorrow as I'll be driving all day. Been on travel for the past week and a half, back on Thursday. If someone could send me the meeting log I'll get it posted to the web site as soon as I can. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
I added a page to our wiki about the upcoming file format for account data. It focuses more on the nuts and bolts of the file format itself rather than the APIs used to access the data. In particular, I wanted to get the mail account format written down somewhere since it's a bit more complex than the rest. http://live.gnome.org/Evolution/ESourceFileFormat Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Last minute "vfolder-prep" branch merge
Srini asked me to merge his "vfolder-prep" branch in time for Evolution 3.4, and I wasn't around much last week so this is kind of last minute. This branch just stages some of the vfolder and filtering code to be moved to Evolution-Data-Server after 3.4. The GTK+ parts of some of those classes have been split into separate "ui" subclasses, similar to how EMailUISession was forked from EMailSession. The branch also introduces yet another little utility library named libevolution-utils. This is just a temporary library. The plan is to move its APIs into libedataserver[ui], but it's a little late to do that for 3.4. The library contains most of the EAlert APIs and some other odds and ends from libeutil, so that created a bit of a splash across the source code. I know it's bad juju to do this right before a release, but the source code is only being reorganized, Srini assures me it works well, my own testing seems to confirm that, and I'm doing my due diligence to make sure everything builds smoothly for Monday's release. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] listening to signals from the message list
On Tue, 2012-03-06 at 17:06 -0300, David Roguin wrote: > I'm writing a simple evolution extension. I've arleady have access to > the mail shell_window, but the problem I have is I can't find a way to > receive an event whenever the user select a message from the mail > list. > I've unsuccesfully tried to look for a GtkTreeView on the ui_manager > and I couldn't find anything in the EShell* docs. > > If anyone could point me into the right direction I'd be grateful. If you need the selected CamelMimeMessage as shown in the preview pane, I recently added an EMailReader::message-loaded signal that you can tap. See the "mdn" module for an example of connecting to this signal: http://git.gnome.org/browse/evolution/tree/modules/mdn/evolution-mdn.c Hope this helps, Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Archive button - new feature
On Thu, 2012-03-22 at 16:43 -0300, David Roguin wrote: > I've been working on adding a button that mimics the functionality of > the Archive button of a gmail account. If you ever used gmail from the > web client you know what I'm talking about, for the rest: it's a > button that moves the selected email to the 'All mail' folder. Of course the "All Mail" folder is specific to GMail/IMAP. So is this button only shown for GMail/IMAP accounts? If not, what does it do for other account types or non-GMail IMAP accounts? Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Archive button - new feature
On Thu, 2012-03-22 at 17:17 -0300, David Roguin wrote: > Yes, it will only show for gmail accounts. On a second thought it > could provide a shortcut to move the emails to any specific (user > choosen) folder I'm in favor of making it a generic "move message to pre-defined folder" action, automatically configured as "All Mail" for GMail/IMAP accounts. Choosing the designated "archive" folder would fit nicely in the "Special Folders" section of the Account Editor window, perhaps with a check box for users who prefer not to manage their mail like that. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Start your engines for Evolution 3.5.1
You may have noticed Evolution 3.4.0 and co. has been released and I've created 'gnome-3-4' branches for all modules except 'evolution-mapi' and 'evolution-kolab' (but I assume Milan and Christian will take care of those shortly). That means the 'master' branches are open once again for 3.5.1 development to begin. So have at it! Keep in mind the gnome-3-4 branches are permanently under a string, UI and API freeze -- in case you have any bug fixes to backport for 3.4.1. Thanks for everyone's help with Evolution 3.4. This new development cycle towards Evolution 3.6 should prove to be interesting. :-) Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit branch is ready
On Wed, 2012-03-28 at 06:43 -0400, Daniel Vratil wrote: > WebKitGtk+ 1.8.0 with the important patch has been released last night, > and so everything is in place now and I'm ready to break^W merge to > master. The branch has been rebased two days ago, I will only bump the > webkit dependency version later today. > > I hereby ask you guys for review and approval for the merge. Awesome! I'm eager to try it out. Also, do you have a blog? Is it syndicated on Planet GNOME? If not I can do it, but people need to know about this and your upcoming plans for the composer, and subsequently killing off GtkHtml once and for all. The community has been waiting for this for years! > I'd suggest creating 4 or 5 new commits directly in master instead of > actual git merge to avoid polluting master history with nearly 200 > commits of my furious development :) I'd suggest running "git rebase -i HEAD~200" (or however many) on your branch and squash the commits down yourself, and then merge the result. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Archive button - new feature
On Wed, 2012-03-28 at 12:17 -0300, David Roguin wrote: > Ok, it sounds great. > I have one question then, I was coding this functionality as an > extension, is it possible to add the "archive folder" option into the > "special folders" section with an extension? At present, no. But I've completely rewritten the account editor on a branch I'm hoping to merge during 3.5, and I can easily add a hook for adding your button from an extension. What you'll wind up doing is writing another EExtension subclass that targets this class, which is not yet in 'master' branch: http://git.gnome.org/browse/evolution/tree/mail/e-mail-config-defaults-page.h?h=account-mgmt Then I'll add a new function to that class for you to call to append a new button. Not sure exactly what it will look like yet. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory corruption bug in timezone handling
On Thu, 2012-03-29 at 10:33 +0100, Robie Basak wrote: > I've been investigating a memory corruption issue in evolution which > causes a crash on my system. I think the problem crosses an API boundary > and resolving it is non-trivial, so I'd like to better understand what > is supposed to happen. Any insight into this would be appreciated. > > The problem seems to be that > icaltimezone.c:icaltimezone_get_builtin_timezone calls icalarray_append, > which moves the entire array to grow it. But an ECalShellView is > maintaining a pointer inside that array (via a very long chain of > indirection) which becomes invalid as the array is moved. This causes > later corruption, invalid reads from freed memory, and eventually > segfaults from both the corruption (which appear quite random). I thought this was solved already by: http://git.gnome.org/browse/evolution/tree/modules/calendar/e-cal-shell-backend.c#n863 Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory corruption bug in timezone handling
On Thu, 2012-03-29 at 12:30 +0100, Robie Basak wrote: > I spotted this, and this workaround is in my source tree too. But it > doesn't seem to work. The array is still being moved as a result of > icaltimezone.c:icaltimezone_get_builtin_timezone by the following code, > which seems to be an edge case that the workaround does not cover: Hmm. When I wrote that workaround I was under the impression that an upstream libical fix was imminent. Perhaps we just need to bump our minimum libical requirement, or is upstream still not thread-safe? Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote: > Next part is, that I think network (un)availability and Evolution/E-D-S > online/offline state are two separate things, which got mixed in the > current implementation. Network unavailability means I cannot write my > objects onto the server. In evolution-kolab, whenever a PIM object is > saved, it is first stored in the local write cache. If in "online" > state (as in Evo 2.30 semantics), evo-kolab would then try to push the > object onto the server, which may fail due to a multitude of reasons - > server down, network line shaky (connection dropouts), > firewall-of-the-day is active or whatsoever. The PIM object then simply > stays in the offline cache, waiting for a later successful sync with > the server. Still not sure how synchronization should be triggered in the UI, but I like the idea of a synchronize() method for EClient. I think being able to explicitly say "synchronize my changes now" is an important use case that we're lacking at the moment. Conflict resolution is a tricky case that to my knowledge we've not really dealt with before. I don't think a UI for conflict resolution necessarily has to be programmed into Evolution. In fact I'd prefer it isn't since it would leave other E-D-S clients out in the cold. Instead the backend itself could spawn off some specialized GTK+ process that pops up a conflict resolution window. Then we wouldn't have to worry about stuffing conflict resolution methods into the client-facing APIs. It would be automatic as far as E-D-S clients are concerned. As for Evolution's forced offline mode feature: at present it only applies to mail since mail is still in Evolution's exclusive domain. Once mail joins address books and calendars as a desktop-wide service with potentially multiple apps acting as clients, I plan to remove Evolution's forced offline mode entirely since it won't be applicable anymore. This is part of my campaign for one E-D-S client to not get special privileges over other E-D-S clients. We need to forget about the 'E' in E-D-S. That said, EBackend's online detection _is_ too simplistic at present. I'd like to make each EBackend determine its own online/offline state by way of g_network_monitor_can_reach(), but I'm holding off on that until my account-mgmt branch is merged, so EBackend will have a consistent way of getting the server address to feed to GNetworkMonitor. Still, seems doable by 3.6. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Might want to repost your full message to the list. I assume you didn't
mean to reply to me privately?
On Tue, 2012-04-03 at 16:05 +0200, Christian Hilberg wrote:
> Well okay, that's a little more than the current EBackend "online" property,
> since it can tell me whether a certain host can be reached. But, AFAIK, it
> can not tell me whether a given *service* on that host can be reached (that
> is, can be connected to), right?
g_network_monitor_can_reach() takes a GSocketConnectable -- which is
just an interface that's implemented by several concrete classes like
GNetworkAddress (based on host name and port number) and GNetworkService
(based on SRV records), so I assume service will be taken into account
when possible in determining the boolean result that would feed into
EBackend's "online" state.
Probably it would make sense to add an EBackend method which returns a
GSocketConnectable ("get_socket_connectable"?) so backends can specify
to use SRV records when applicable. Not sure if this would be useful
for Kolab servers or not.
Matt
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Tue, 2012-04-03 at 10:40 -0400, Matthew Barnes wrote: > g_network_monitor_can_reach() takes a GSocketConnectable -- which is > just an interface that's implemented by several concrete classes like > GNetworkAddress (based on host name and port number) and GNetworkService > (based on SRV records), so I assume service will be taken into account > when possible in determining the boolean result that would feed into > EBackend's "online" state. Seems I'm assuming too much. Dan Winship advises me that g_network_monitor_can_reach() merely checks if there's a route to the host, but doesn't actually connect. Would it make sense to split the "online" state into two flags, perhaps "host-reachable" and "service-available"? The latter would reflect the result of actually trying to connect to the service to see if something answers, obviously only attempted if "host-reachable" is set. These could both be class methods in EBackend so backends can tailor them as needed. For example, an HTTP server may well respond alright, but with a "501 Service Unavailable" which should interpreted as FALSE. Would this distinction be useful to backends? Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Tue, 2012-04-03 at 17:29 +0200, Christian Hilberg wrote: > Seems to me that opening a connection in order to find out whether I could > open a connection is more than evo-kolab would need. Unless the > "service-available" > check would be really cheap, it seems to me that "host-reachable" would > suffice. Once I actually try to connect and fail, I know that I cannot > connect. Nothing lost. ;-) (What's more, if "service-available" was TRUE half > an hour ago, when the check was made, that does not automatically mean that > it is still TRUE when I want to actually *use* the connection half an hour > later - so, not sure whether a "service-available" check would help much). Perhaps then simply rename the "online" property to "host-reachable" to clarify it's meaning as a first step? "Online" seems like too nebulous a term in this context anyway. Beyond that you can probably tell I'm flailing around for a coherent story. What I had in mind for "service-available" was a way to notify the client app to just disable certain actions for that account to avoid repeated "Service Unavailable" error messages. But then two questions spring to mind: 1) If a backend can queue up changes offline to be synchronized with a remote server later when it's available again, does that imply its "service-available" flag should remain TRUE always? 2) If a backend CANNOT queue up changes offline, how then should it determine when the remote server becomes available again? Poll? Allow the user to say "try again"? I think I'm lacking insight here, so advice is appreciated. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote: > How about the "service-available" to be set much like the to-be > "network-available", through GNetworkMonitor, as an EBackend property, > which, when changed, emits a signal? > > Just rough thinking, nothing elaborate as yet - I'll be meditating > this. :) First question to iron out is, supposing we have such a flag, who is meant for? The backend itself or client apps like Evolution? I'm leaning toward the latter. In fact, as I iterate on this idea, it seems the backend probably knows best and should be _setting_ this flag itself rather than being told. But yes, it would be a boolean GObject property with change notification signals for the local process, and hopefully also a D-Bus property with change notification signals for client apps via GDBus. Rough thinking here too. I'll let it simmer. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote: > How about the "service-available" to be set much like the to-be > "network-available", through GNetworkMonitor, as an EBackend property, > which, when changed, emits a signal? > > Just rough thinking, nothing elaborate as yet - I'll be meditating > this. :) We discussed this briefly on IRC, but just to follow up more formally. Having stewed on this overnight I think we're coming at the problem wrong. The question boils down to "can the backend operate on its data set or not?" That status is as much as we need to expose to clients, I think. Network availability and remote server availability factor into the answer but clients need not care. If a backend is offline-capable, then the answer -- as far as the client is concerned -- is always "yes". Here's the set of properties I propose for EBackend to replace the current overly simplistic "online" flag: "host-reachable" type: boolean perm: read-only default: false EBackend itself updates this as a convenience for subclasses, but this status need not be exposed to client applications. For network-based backends, this property is the result of running g_network_monitor_can_reach() on startup and in response to changing network conditions or when the "socket-connectable" property changes. For local-file backends, the host is assumed to be "localhost" which is always reachable. So the property will always be TRUE for them. "socket-connectable" type: GSocketConnectable perm: read-write default: (see below) This is the GSocketConnectable fed to g_network_monitor_can_reach(). EBackend itself will initialize this to a GNetworkAddress based on the host and port settings in the ESource. Subclasses do have the option of overriding this, however, which is why it's read-write. If the pointer is NULL, this is assumed to mean "localhost". Setting this property will trigger a "host-reachable" notification after EBackend runs g_network_monitor_can_reach() on the new value. This property could prove to have additional uses in the future as we further embrace GIO's networking APIs. "readable" type: boolean perm: read-write default: false This property is exposed to clients. It indicates the backend's data is viewable but not necessarily complete, as in the case of a network outage and not having fully synchronized for offline usage. Backends are responsible for updating this themselves. Clients are responsible for disabling the relevant UI elements when this property is FALSE. "writable" type: boolean perm: read-write default: false This property is exposed to clients. It indicates the backend's data can be modified, but possibly only locally. Reasons it may be FALSE include the remote host not being reachable, the service running on the remote host not being available, or the service forbidding write access to the data (such as for "On The Web" calendars). Backends are responsible for updating this themselves. Clients are responsible for disabling the relevant UI elements when this property is FALSE. Under this scheme, client applications don't need to know about network or service availability -- just whether the backend can currently handle a particular user action. I think this simplifies things greatly. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Wed, 2012-04-04 at 21:25 +0100, Philip Withnall wrote: > Nitpicky, but what happens if a backend has to deal with multiple hosts? > The only example I can think of at the moment, and it's a stretch, is > the Google Contacts backend. It connects to one host for authentication, > and a different one for Contacts operations. Most of the time, GOA will > take care of authentication, so this really is a tiny corner case, but I > guess it's worth considering. > > I suppose we would just use the Contacts operations host for the > purposes of "socket-connectable", and treat failure to connect to the > authentication host as a transient authentication error. Agreed. More broadly I'd say "socket-connectable" should point to where the data lives. If that's not reachable then there's really no point in authenticating, whether _that_ host is reachable or not. > I might be tempted to give the user feedback about why a backend is > _not_ writeable (somehow, perhaps a "writable-reason" enumerated > property). This could be useful when setting up a backend: the backend > might report itself as non-writeable, but the user would not know > whether this is because they've made a typo in the backend's URI, or > because they've used a read-only URI instead of a writeable one. Or > something like that. That's worth considering, though it might already be partially covered just by backends returning error messages on failed operations as per normal. That includes open(). > Overall, this set of properties seems to simplify things nicely though. > It also fits in well with the offline buffering stuff Milan and I have > been discussing (with a few other people CCed). Good! That at least validates I'm not _completely_ off the mark. :) Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Thu, 2012-04-05 at 12:05 +0200, Christian Hilberg wrote: > This is why I propose a dedicated offline state, which is not dependent on > network availability, and which is visible to the user by being displayed > in each client that connects to E-D-S. Such a state makes it very clear to > both, user and backends, how to act and what to expect during the workflow > (for instance, there cannot be any sync conflicts while working in offline > mode - the user just plainly does not expect to see any in this case). > It also seems that online or offline is not a state the E-D-S clients need > to maintain, but it is rather a status E-D-S itself maintains (and tells it > to its backends as well as to any client that connects and has the capability > to display E-D-S's current status). Once a client requests E-D-S to change > online/offline operational mode, the change request can be propagated to > both, all backends which do implement a notion of online/offline operational > mode, as well as to any client connected to E-D-S which has the capability > of showing E-D-S state. Need to think on that some more, but can we at least agree that capability would be _in addition_ to the properties I proposed for EBackend, so I can start implementing a few of them? Trying to get consensus on some initial steps here and not debate this to perfection before anything gets done. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution's GTK+ requirement
Given all the scrolling and selection bug reports I'm seeing from GTK-3.4 users, none of which are present when building against GTK-3.2, I suggest we keep our minimum requirement at GTK-3.2 until these issues get sorted out, either by us or by Xorg/GTK+ developers. The problems seem to have started when GTK+ 3.3.x switched to XInput2. I don't know the details, but my guess is there's some behavior changes and GDK's X11 backend was written to the old XInput behaviors. Being able to build Evolution 3.5 against GTK-3.2 to prove these are not our regressions is useful. I don't see any particularly compelling new APIs in GTK-3.4 anyway. Sound okay? Any objections? Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] moving messages is visually slow
On Tue, 2012-04-17 at 11:10 -0300, David Roguin wrote: > I've noticed that moving messages takes considerably more time than > deleting them. Visually when I delete a message I see the item > disappear almost instantly, I'd like to achieve the same thing when I > move a message. > > Is there any way to achieve this? Maybe hiding the selected items and > then move them? I couldn't find anything related to hiding messages > (except a boolean for hiding the deleted ones) "Deleting" a message really just tags the message to be deleted when the mail folder is expunged at some later date. It's a fast local operation which you don't even have to be online for, since tags are synchronized with remote mail servers in batches. You can do "View -> Show Deleted Messages" and see the messages tagged for later deletion. Your Trash folder, by the way, is just a live query for these tagged messages across your entire account. "Moving" a message involves appending a copy to the destination folder and then marking the original for later deletion. This naturally takes much longer, and we don't want to mark the original message for deletion until we're sure the copy was successfully appended to the destination. Otherwise we risk data loss if the append fails for some reason. I suppose we could play more tricks with the message list to give the appearance that messages are removed instantly, but the message list is already rife with such tricks, and each new one makes it harder to keep the logic clear and thus harder to maintain. I'm happy to review a patch, though, if you still want to attempt it. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution's GTK+ requirement
On Tue, 2012-04-17 at 22:25 +0100, David Woodhouse wrote: > It's a constant PITA that you have to have the latest versions of > *everything*, when in practice most of those dependencies aren't really > true at all. That's not true for Evolution. We don't require unstable releases of base libraries, but anything in the most recent stable release is fair game. That way we can utilize new features at a reasonable pace without forcing contributors to run a whole bleeding-edge desktop just to hack on a bleeding-edge app. GTK+ 3.4 was included in the module set for GNOME 3.4, so it's fair game for Evolution 3.5.1. But I'm asking that we hold off for a little while longer for the aforementioned reasons. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] moving messages is visually slow
On Tue, 2012-04-17 at 17:03 -0600, Zan Lynx wrote: > Please make sure that you have a good way to inform the user so that he > knows Evolution is busy. He needs to know when it is okay to suspend the > laptop or pull the networking cable out. That's what the task bar at the bottom is for. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
It's been awhile since I've posted a progress update on this branch, but I just wanted to mention that as of this weekend I think I finally have Evolution pretty much wrapped up now and am moving on to the groupware modules starting with Evolution-EWS, since I'm also on the hook for integrating EWS with the new Exchange support in GNOME Online Accounts. I'm sure I'll have more tweaks and bug fixes for Evolution and E-D-S, especially since I haven't really handled groupware accounts under the new ESource API yet, although I've tried to anticipate what we'll need. I already have patches written for the GNOME Shell calendar and GNOME Panel calendar applets, and have alerted the Telepathy/Folks developers about the upcoming breaks [1]. I tried to patch the E-D-S Folks backend myself but my feeble Vala skills just aren't up to the task. So I think I'm on track to merge this branch during this cycle, though I dare not predict a merge date just yet. I think once I finish off EWS I'll have a much more accurate sense of the remaining work ahead of me. I rebased both Evo and EDS branches on 3.5.1 today, so feel free to try them out if you're curious. Just be cautious of the account migration: it's a one-way trip. Maybe test it on a different user account for now. Matthew Barnes [1] http://lists.freedesktop.org/archives/telepathy/2012-April/006072.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote: > It has already been agreed upon (see previous posts in this thread) that > such a synchronize() function is needed and that it can be triggered > from the EClients in a sensible way. Question is, how and when will it > be implemented so we can test the migrated evolution-kolab parts waiting > for that. Probably someone just has to do it. Unfortunately I'm under heavy pressure from Red Hat to finish my branch ASAP, so I'm booked solid until probably early to mid-June. Maybe this is something Milan can take up, or even you yourself could start on the E-D-S side if you're not too busy. Roughing in the new D-Bus method should be a fairly simple first step. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Bug#623066, Me, Evolution, & jhbuild
On Thu, 2012-05-10 at 09:38 -0400, Adam Tauno Williams wrote: > I'd like to test the changes regarding Bug#623066 and possibly others. > > Is there anything special I need to do to get jhbuild to create the > correct version/branch of Evolution? Or, initially, can I achieve the > correct version via jh? Not a jhbuild expert but I believe it builds the HEAD revision of the "master" git branch by default (currently version 3.5.2). Or you can choose a stable branch by setting the 'moduleset' variable in your ~/.jhbuildrc appropriately. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution module renames
Just a heads up that I renamed Evolution's module libraries. libevolution-module-foo.so --> module-foo.so So make sure you either "make uninstall" or clean out your installed modules directory ($PREFIX/lib/evolution/3.6/modules) before your next rebuild, otherwise you'll have duplicates of each module installed and that will likely cause some strange behavior. Rationale: Now that I'm writing modules for evolution-data-server on my account-mgmt branch I needed a good file name for them. "libevolution" obviously doesn't fit in E-D-S and I couldn't think of anything I liked better so I just dropped that part and wound up liking the result -- so much so that my obsessiveness about consistency got the better of me on the Evolution side. :) Beyond requiring a clean reinstall the change should be transparent. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What about removing camel_folder_has_search_capability()
On Thu, 2012-05-17 at 13:31 +0200, Milan Crha wrote: > thinking about all the upcoming changes, what about removing also > camel_folder_has_search_capability() and its corresponding flag? +1 Do it. The less flags the better. > P.S.: Maybe the same applies for the > camel_folder_has_summary_capability(), but I do not want to go that far, > at least not yet; also because it is used in camel-filter-driver.c. If there turns out to be a real use case for this, would be nicer to replace the flag with an interface, similar to the CamelSubscribable interface replacing the CAMEL_STORE_SUBSCRIPTIONS flag. Not sure what to call the interface off-hand, but it could just consist of the get_summary() and free_summary() methods in CamelFolderClass. I suspect we won't find a real use case though, and can probably just drop the flag. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
On Tue, 2012-05-22 at 16:38 +0200, Christian Hilberg wrote: > camel-imapx-tokens.txt is the file which is fed to gperf, and the > resulting structs are used by the IMAPX tokenizer. > The tokenizer is called inside imapx_untagged, and its result is > switch()ed on, and the extended untagged handler function, which can > be registered, is called in the default: block of that same switch > statement. At this point I would advocate ditching gperf and just building an internal hash table of known tokens which subclasses can extend. The tokens could be internalized with g_intern_string() to save a few string comparisons, but I can't imagine that's a huge performance hit in the face of network I/O. I haven't really looked closely as how gperf is used within the parser, so this is admittedly hand-wavy. But clearly a static hash function built from a text file is not going to be extensible the way we need. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
On Wed, 2012-05-23 at 18:40 +0200, Christian Hilberg wrote:
> As dwmw2 just pointed out on IRC, it really isn't.
> The data structures which the derivative untagged handlers
> need to access can/should best be bound to the derivative
> CamelIMAPXServer. In fact, that is exactly the way it works
> in my 2.30 approach, only the data structures were not bound
> to a derivative, but to the original CamelIMAPXServer. Binding
> to the subclass would be the only change needed here.
I'm not letting myself get sucked into this enough to go read IMAPX code
right now so this might be off the mark, but another pattern to consider
is to define a base struct that represents a response:
struct _CamelIMAPXResponse {
volatile gint ref_count;
/* the hash table key */
const gchar *token;
/* the server that created this */
CamelIMAPXServer *is;
void (*handle) (CamelIMAPXResponse *response);
void (*destroy) (CamelIMAPXResponse *response);
};
You could then extend the struct for various tokens and embed the
payload directly in the extended response struct:
struct _MyCustomResponse {
CamelIMAPXResponse parent;
/* response-specific payload goes here */
};
The benefit here is the response handler function and the payload stay
together at all times, and the extended struct knows how to clean up its
own payload through its destroy function.
Then for each type of extended response struct you write a factory
function that just allocates and initializes an instance of your
extended response struct, but casts it to a CamelIMAPXResponse:
CamelIMAPXResponse * my_custom_response_new (CamelIMAPXServer *is);
Then in the token table that lives in CamelIMAPXServer, instead of
registering direct handler functions for various tokens you register
these factory functions.
So the server logic looks something like:
typedef CamelIMAPXResponse *
(*CamelIMAPXResponseNewFunc) (CamelIMAPXServer *is);
CamelIMAPXResponseNewFunc new_response_func;
CamelIMAPXResponse *response;
/* Look up a factory function for the given token. */
new_response_func = g_hash_table_lookup (hash_table, token);
/* Create a new response instance. */
response = response_new_func (is);
...
/* Invoke the handler function. */
response->handle (response);
...
/* Unref the response. If the ref_count reaches
* zero the response's destroy function is called. */
camel_imapx_response_unref (response);
Maybe this is overkill for this particular issue since I'm not familiar
with the use cases for the payload data you speak of.
It's certainly more tedious to write in C but offers more flexibility
than a mere function pointer.
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] Retiring evolution-exchange
The release of Evolution-ActiveSync brings the number of Evolution Data Server backend modules for Microsoft Exchange up to four. Even if we had the manpower to adequately maintain all these, which we don't, four different backends for one product is getting ridiculous. Therefore I think it's time to retire Evolution-Exchange. That module has seen steadily decreasing maintenance for several years, the newest version of Exchange it supports is now a decade old, and frankly it was never all that reliable anyway. As with any Free Software project, retiring Evolution-Exchange simply means we will cease issuing new tarballs. 3.4.x will be its last stable release series. Any interested party is of course welcome to resurrect the project and issue new releases. If we have consensus on this I will announce it. At this time I have no plans to adapt the module to the upcoming API changes. 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] Merging the account-mgmt branch this weekend
lot more work to be done here to fully realize what I have in mind. * There will be API breakage at all levels of Evolution-Data-Server, but most severely in libedataserver. ESourceList, ESourceGroup, EAccount, and EAccountList are all gone, replaced by ESourceRegistry. ESource still exists and is conceptually the same as before, but its API is completely different now. It's basically a glorified key file interface with a few asynchronous D-Bus methods. ESource also now handles mail accounts, unifying at last all account management under one API. The new libedataserver and libebackend APIs are documented here: http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ http://mbarnes.fedorapeople.org/account-mgmt/docs/libebackend/ * The account editor and the calendar and address book configuration dialogs have been rewritten from scratch. They no longer use EConfig, nor even EPlugin at all. They are now extended through EExtensions. Now that the config editors are liberated from EPlugin, I'd like to take a serious look at moving them to Evolution-Data-Server. I still need to figure out the details there. * Lastly, the test suite in Evolution-Data-Server is pretty borked at the moment. I hope to get the test suite operational again by 3.6. Now that account information is stored in XDG-compliant directories, we should be able to create a much nicer and fully automated test harness that doesn't risk interfering with your own accounts. I have several patches prepared already for other projects to help them quickly adapt to the API breaks. I'll also be blogging about this today or tomorrow. Matthew Barnes [1] Thread starts here: https://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html [2] http://developer.gnome.org/gcr/unstable/GcrSystemPrompt.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] Retiring evolution-exchange
On Thu, 2012-05-24 at 16:15 -0400, Matthew Barnes wrote: > Therefore I think it's time to retire Evolution-Exchange. That module > has seen steadily decreasing maintenance for several years, the newest > version of Exchange it supports is now a decade old, and frankly it was > never all that reliable anyway. I'm adding Evolution-GroupWise to the retiree list, since it no longer has any active maintainers. Haven't heard any objections so I take that to mean consent from the rest of the team. I don't plan to release any more 3.5 tarballs for these packages but I'll sit on the announcement until after the dust from the account-mgmt merge settles. 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] Retiring evolution-exchange
On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: > Then why not retire evolution-mapi instead of evolution-exchange ? I hadn't considered that. I'll defer to Milan to make that call. I thought evolution-mapi worked with Exchange 2003 servers at least in theory; I don't know how much actual testing that's had. And I know Milan has been maintaining evo-mapi more actively than evo-exchange and has a good working relationship with the OpenChange developers. In any case, maintaining this many different backends for Exchange is ridiculous and we need to drop at least one of them given our manpower shortage. I guess I don't care so much which, and am probably not the most qualified to choose. What do you think, Milan? > I do understand that you looked at the code updates and available > developers to decide. It would also be good if we choose what to support > based on, what would work as a good enterprise solution. I say > enterprise since we are here talking about exchange and groupwise. > > W.r.t evolution-groupwise, it would be good to continue it until this > release. I second the reason which Akhil has mentioned in another email. > We would also need to give it sometime to see if there are people > interested in contributing there. The thing is, all of these modules are going to require significant work to adapt to the branch I'm about to merge -- groupwise perhaps even more than the rest -- and given that I don't even have access to a GroupWise server to test the changes I'll have to make to it, I'm highly resistant to bothering with it if it's not going to have a full-time maintainer going forward. If someone were to step forward as at least a short-term maintainer that could help test the changes, I would reconsider. I will, however, release an evolution-groupwise 3.5.2 with the changes you made recently for it. That's a fair request. 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] Retiring evolution-exchange
On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: > W.r.t evolution-groupwise, it would be good to continue it until this > release. Sorry, I read "this release" to mean 3.6. If you just meant 3.5.2 then I guess disregard my other response. Haven't had my coffee yet. :) ___ 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 port of the composer
On Fri, 2012-06-01 at 16:49 +0200, Daniel Vratil wrote: > I have nearly finished reworking the e-mail formatter (details in the other > mail) and I want to slowly turn my attention to the composer. It will be a > lot > of work, but hopefully I'll make it for 3.6 (no, I WILL make it for 3.6!!!). Awesome that you're starting in on that already! 3.6 is pretty ambitious though. We can't be landing major features too late in the development cycle and 3.6 is already a doozy. You need to allow adequate time for testing and bug fixing before a stable release. 3.7.1 seems a more realistic target. I'd be no less thrilled to be rid of GtkHtml by 3.8. > If you have any special wish (I bet Andre will come with many feature > requests > from bugzilla :P ) you'd like to have in the new composer, please share them > now. Regarding features, I want to make exact copy of GtkHTMLEditor and only > fix the most annoying GtkHTML issues, all crazy ideas will be deferred for > 3.8 > :) Sounds pretty reasonable. My only request off the top of my head is to not subclass GtkWindow for your simple/html editors like GtkhtmlEditor does. That was a mistake on my part because it precludes us from embedding the editor in an existing window, and you'll likely want to do that later when you start working on a Conversation View. ;) I suggest GtkGrid as a base class. Out of curiosity, what does WebKit/GTK+ use for spell checking? Enchant? Will their APIs allow us to recreate the context menu with spelling suggestions plus other editing actions? 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] Retiring evolution-exchange
On Fri, 2012-06-01 at 08:39 -0600, Vibha Yadav wrote: > > On Fri, 2012-06-01 at 15:19 +0530, Chenthill wrote: > I can provide you the support. I will be getting into the new project > coming Monday. I can keep myself involved during free time after a > couple of weeks time.. > I can also contribute in my free time as well for GroupWise. As > exchange, EWS and GroupWise are good enterprise solutions for > Evolution. Fair enough. I'll try to make the necessary changes some time after the merge and then hand it off so you guys can tell me what I broke. :) 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] Retiring evolution-exchange
On Fri, 2012-06-01 at 19:49 +0200, Milan Crha wrote: > evolution-ews >- for 2007,2010 servers (through https, with simpler dependencies) >- it's currently semi-maintained >- note the EWS implementation on Exchange servers is not feature > complete on 2007 servers (I read/saw some articles about it some > time ago) Exchange Web Services is also a publicly documented SOAP API. Our other Exchange backends are based on reverse engineering of a proprietary, now deprecated API (in the case of MAPI) or something that was never really meant to be an API at all (in the case of OWA). To me that gives EWS the most staying power going forward. That's the one to really focus on. GNOME is also more deeply invested in it now by way of GNOME Online Accounts. > That said, I would deprecate evolution-exchange, but only from active > maintenance, we still want to support it, as it's proved as working by > years and its users. The passive maintenance will be only consisting in > basic functionality testing and making sure it is compileable with > current eds/evo (testing after changes). I know it's more work for you, > Matthew, but I also believe that once the API changes will be finished > (after 3.6.0), the whole passive maintenance will be a toy, with less > frequent releases than on the other projects. You sure you want to be dragging around that much redundancy when it's just you, me and Dan part-time? I promise I'm not just trying wiggle out of some work I don't want to do, but I'm trying to think long-term with just us two-and-a-half men. And I don't see us picking up any other core maintainers any time soon. I think you're underestimating the maintenance burden, even if we're not actively fixing bugs anymore. The client-facing APIs have been stable and I think even the new ESource APIs are already pretty stable having refined them for a year and a half. The backend-facing APIs less so. They tend to see more churn anyway, even without my branch. I can't think of a recent release where the backend APIs didn't change a little. And that's fine -- the damage is contained -- but we still have to go touch all the backends for every API change and some of those aren't trivial. And especially with this new E-D-S architecture I've cooked up, which is an improvement but still far from perfect, I think we'll be seeing a rash of backend API changes over the next few devel cycles. So I'm not really buying the "toy" argument. I'm sad to lose the Novell folks but I'm trying to make the best of it by treating this an an opportunity to dump some old baggage so we have a leaner code base to focus on, even if that means leaving a few users out in the cold. No one is going to seriously criticize us for wanting to lighten our load after our team just got sliced in half. To be honest, I was being conservative in suggesting we only cut _one_ Exchange backend loose. 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 port of the composer
On Fri, 2012-06-01 at 18:38 +0200, Dan Vratil wrote: > > That was a mistake on > > my part because it precludes us from embedding the editor in an existing > > window, and you'll likely want to do that later when you start working > > on a Conversation View. ;) > > I probably missed something...? :) I was kidding... Sort of. ;) > Yes, they use Enchant. The API [0] seem to be able to return only single word > > for autocorrect, but I guess we can fill in the missing functionality by > working directly with Enchant? Good, then you may want to salvage the spell/language classes from GtkhtmlEditor, which also talk to Enchant. I wrote those a few years ago based on a GLib proposal called GSpell that never went anywhere. It's still languishing in Bugzilla. If ever GLib does grow some spell checking support, it's likely the API will be similar. 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] A better mail formatter
On Fri, 2012-06-01 at 19:10 +0200, Dan Vratil wrote: > I have realized that the formatter could be made much more flexible and nicer > by making proper object-oriented design. With Milan we have came up with > quite > a nice design. That sounds freaking awesome! > The first big step is to move everything to libemformat. Why have something > here and something there. I vaguely recall EMFormatHTML had some mail-specific dependency that kept it in the mail library, but maybe that's long since been solved. It totally makes sense to consolidate if that's indeed possible now. > The parser and formatter were separated to their own classes EMailParser and > EMailFormatter and the _actual_ parsing/formatting is done by extensions. > Essentially there is a class for each mime type we support and they are > derived from EExtension. I'm literally crossing an item off my own To-Do list now. Nice! > As part of the work, I converted some plugins, namely audio-inline, itip- > formatter, prefer-plain, tnef-attachment and vcard-inline, to modules. There > is no API yet to extend the preferences dialog though, so for this some of > them still install a little EPlugin-based library with the GUI. That would be itip-formatter and prefer-plain, right? Nowadays I'm not sure the Preferences dialog should even be extensible at all. It's too tempting to just tack on options willy-nilly without giving them sufficient thought. If something's important enough to show up in the application preferences then it probably ought to live in the core application. That's just my opinion. I'm inclined to suggest just add those plugin preferences directly. BTW, my branch and your branch will probably collide in itip-formatter, but hopefully the conflicts are easy to resolve. > And why we have done this all? Because of text-highlight module. I've written > less technical blog about it, so see for yourself what we already have and > what I plan for near future. > > http://www.progdan.cz/2012/06/evolution-gets-a-new-e-mail-formatter/ Neat! Does the text-highlight have to be chosen each time or is it remembered somehow? 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] Merging the account-mgmt branch this weekend
On Thu, 2012-05-31 at 12:39 -0400, Matthew Barnes wrote: > This is a heads up that I will be releasing Evolution 3.5.2 and co. this > weekend and then merging the account-mgmt branches for E-D-S, Evolution, > and Evolution-EWS. Evolution-MAPI will follow sometime after the merge. The account-mgmt branch is now merged for 3.5.3. For the inevitable flurry of bug reports which will now commence, if you could please tag them with "evolution[account-mgmt]", that would help me track them more easily and respond faster. Current status is EWS is ~90% done. It's functional, just a few loose ends to wrap up. My priority for this week will be submitting patches to affected projects to help them adapt to the API breaks, and also deal with whatever critical issues you guys find. Once the major regressions are under control, I'll start in on MAPI. With any luck I'll have MAPI ready by 3.5.3. I'll get to the other groupware backends in due time. 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] Front-end header files for E-D-S libraries
On Tue, 2011-03-22 at 14:35 -0400, Matthew Barnes wrote: > For 3.1, I would like to provide a top-level header file for each of the > libraries in E-D-S and deprecate including individual header files. The > benefits should be clear by now: more flexibility to change or rearrange > header files without breaking the public API. > > Valid #include directives for E-D-S libraries will be: > >#include > >#include > >#include > >#include > >#include > > I'm not bothering with the backend libraries just yet. They're less of > an issue than the client-side libraries. > > To enforce this we'll use the same mechanism as in GLib and GTK+, except > for now we'll issue a #warning instead of an #error: > >#warning Including directly is deprecated. >#warning Please use #include instead. > > We could also test for an EDS_DISABLE_SINGLE_INCLUDES definition which > would issue an #error instead of a #warning. > > After maybe a year or two we'll crack down and issue #errors in some > future 3.(odd).1 release. Since I've already broken E-D-S APIs across the board for 3.5.3, I'm following up on this as well. Same plan as what I originally sketched out, except I'm skipping the deprecation phase and moving straight to #error since there's no point drawing this out, and I _am_ bothering with the backend libraries. It turns out to be nice for backends to just have one #include. 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] Let's set the date for 3.4.3 release
On Mon, 2012-06-04 at 11:35 +0200, Milan Crha wrote: > it's after 3.5.2 and I guess we can set the date for 3.4.3 release now. > It'll be the last planned release in 3.4.x cycle, and the sources > contain few fixes for it already (in various core products). The 3.4.2 > happened on May 14th, thus I'm proposing June 18th for 3.4.3, just a > week before 3.5.3. There are still two weeks for changes, in case of > sever bug(s) being found in the stable release. > > Does it work for others? Thanks for bringing this up, I was thinking about it too recently. Is it just me or was GNOME 3.4.2 released earlier than usual in the schedule this time around? 3.4.2 being the last "official" GNOME 3.4 update, you could say GNOME as a whole had EOL'ed 3.4 before Fedora 17 was even released! That seems kinda hasty to me, but I guess it's a topic for desktop-devel-list. June 18th works for me. I'll pencil that in on the wiki. It's still pretty early in the devel cycle so I wouldn't rule out a 3.4.4 later on if it's needed, maybe around 3.5.90. 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] Retiring evolution-exchange
On Mon, 2012-06-04 at 08:55 +0200, Milan Crha wrote: > What about a "compromise", drop support for evolution-exchange when > 3.7.x development begins? I suppose it'll be fair to have the main API > changes done and any potential community person taking care of it will > not need to learn all the hard changes being done during 3.5.x, thus > it'll be lighter start for him/her/them. Seems I already conceded that for groupwise, so I guess that's fair for exchange too. Sucks more for me but I brought it on myself. :) 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] Updating http://projects.gnome.org/evolution/download.shtml
On Mon, 2012-06-11 at 16:09 +0200, Christian Hilberg wrote: > Would not it be better to come up with some workflow which is hooked > to e.g. the FTP server where new releases trickle in? The process of > updating the download page could even be made automatic - whenever > a new release manifests itself on the primary FTP server, the version > information is pulled from there and the download page updated. No > need to hide Evo's capabilities! :) Updating the download page is documented in the post-release steps of the release process. https://live.gnome.org/Evolution/ReleaseHOWTO#Post-Release_Updates The FTP server to which tarballs are uploaded is shared by the entire GNOME project and we only have restricted user accounts there, but maybe we could wrapper the existing ftpadmin script with additional steps just for us. Or perhaps a simpler solution is to add a little script in gnomeweb-wml alongside the download.shtml page which updates the page based on the "LASTEST-IS" files on the download site. For example, see: http://ftp.gnome.org/pub/GNOME/sources/evolution/3.5/ I guess I've been updating it manually for so long that it doesn't seem like much of a burden, but any effort to make the process more automated is 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] PIM server synchronization and Evolution online/offline state
On Wed, 2012-06-20 at 10:49 +0200, Christian Hilberg wrote: > In our lengthy discussion about that topic, we found that a synchronize() > method is desired for the backends and EClient would expose this in its > API. How exactly the various E-D-S clients will represent this functionality > in their GUI needs to be discussed, but I think this detail is secondary > to the former (i.e. the communications infrastructure which makes it possible > to send a synchronization request to the backends, which they can then handle > in their very own fashion). > > Have there been steps taken already towards implementing this infrastructure? Not to my knowledge, but I think step one is stubbing in a synchronize() method in EClient and relevant backend interfaces. That much should be easy. 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] Subclassable and extendable IMAPX
On Wed, 2012-06-20 at 11:03 +0200, Christian Hilberg wrote: > The result of my work lives in the 'imapx-extensible' branch of > E-D-S. It is still work in progress (the IMAP capabilities flags > need to be made extensible, too), but it is already working and > imapx_untagged() lost most of its amazements. > > All (IMAPX) devs interested in what has been done so far are > welcome to check out 'imapx-extensible' and have a look around > in CamelIMAPXServer and friends. Thanks for your efforts on this! I still haven't reviewed it closely, though we've discussed it a bit on IRC. I hope to find time to do so soon. 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 community meeting at #evolution-meet channel - June 20 - 3:30 PM UTC
On Tue, 2012-06-19 at 16:03 +0530, Chenthill wrote: > As some of you already know, I moved to some other project and > spending most of my time there. At-least during the initial period, I > would not be getting much time for evolution. Matthew would be taking > forward the community meetings hence forth. We decided in today's meeting to end the monthly IRC meetings on account of there being so few Evolution developers left. We agreed this mailing list is sufficient and actually better suited for technical discussions, status updates and upcoming event reminders. We'll hold team-wide IRC meetings as needed henceforth. Discussion of and consensus on this decision is posted here: http://projects.gnome.org/evolution/meeting-logs/2012-06-20.shtml 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] FYI: Some changes in Evolution default assignees/QA in GNOME Bugzilla
On Wed, 2012-06-27 at 14:37 +0200, Andre Klapper wrote: > I transfered the following non-personalized accounts: > > * connector-maintai...@ximian.com-> > connector-maintainers@gnome-bugs > * connector...@ximian.com-> > connector...@gnome.bugs > * evolution-addressbook-maintain...@ximian.com -> > evolution-addressbook-maintain...@gnome.bugs > * evolution-calendar-maintain...@ximian.com -> > evolution-calendar-maintain...@gnome.bugs > * evolution-executive-summary-maintain...@ximian.com -> > evolution-summary-maintain...@gnome.bugs > * evolution-groupwise-maintain...@ximian.com -> > evolution-groupwise-maintain...@gnome.bugs > * evolution-mail-maintain...@ximian.com -> > evolution-mail-maintain...@gnome.bugs > * evolution-plugin-maintain...@ximian.com-> > evolution-plugin-maintain...@gnome.bugs > * evolution...@ximian.com-> > evolution...@gnome.bugs > * evolution-shell-maintain...@ximian.com -> > evolution-shell-maintain...@gnome.bugs > * evolution-tri...@ximian.com-> > evolution-tri...@gnome.bugs > * product-design-b...@ximian.com -> > evolution-product-design-b...@gnome.bugs > > The account tri...@ximian.com was merged into existing > evolution-tri...@gnome.bugs. > The account gtkhtml-maintain...@ximian.com was merged into existing > gtkhtml-maintain...@gnome.bugs. Thanks for taking care of this! I think I tried unsuccessfully to have the ximian.com addresses fixed a few years ago. Glad it inconvenienced someone enough to finally force the issue. :) 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] out of source tree build issue and then installation fails with undefined references in git head
On Thu, 2012-06-21 at 13:54 +, Reid Thompson wrote: > On Thu, 2012-06-21 at 10:27 +0200, Christian Hilberg wrote: > > > > E-D-S commit 4bc0fd235298a75bd055f0954fb48748d8dcbdc8 resolves the issue. > > I still am getting the install failure... Should be fixed now with: http://git.gnome.org/browse/evolution-data-server/commit/?id=918ad005b0a2770be84c2bb13727aa57f166cc81 I had a hard time even reproducing this failure. Finally stumbled on it by accident while rebuilding in a clean environment. Build break alerts are appreciated when stuff like this slips through. 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] Return back folder remember for Open/Save dialog
On Mon, 2012-07-02 at 09:12 +0200, Milan Crha wrote: > Is there any objection? If not, then I'll revert the mentioned commit in > sources next week or so. Please don't. GTK+ claims to handle this now, we should defer to them so our Open/Save dialogs behave consistently with other GTK+ apps. If the policy they've chosen is unpopular, that's their problem to deal with. Please do not override it. 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] Return back folder remember for Open/Save dialog
On Mon, 2012-07-02 at 14:47 +0200, Milan Crha wrote: > Well, they do not do it right, and this kind of "outsourcing" proved to > be problematic in the past, thus why to rely on something nonworking > with "not our fault, ask them to fix it" explanation? I always thought > we do software for people, not people for software. Consistency with other GTK+ applications is more important. If GtkFileChooser has chosen a bad policy, try and open a discussion with Federico about it. Don't just circumvent the policy. I would consider that a regression. ___ 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] Let's set date for 3.4.4 release
On Mon, 2012-07-16 at 09:12 +0200, Milan Crha wrote: > it's a month since 3.4.3 release, and more fixes landed into respective > evolution core products since then, thus I propose to do 3.4.4 release. > > It's harder with the date, as we had 3.5.4 release today, the next week > starts GUADEC and the next Monday after it it's 3.5.5 release. I guess > we can do the release on Monday, July 23, just before the GUADEC and if > anything serious will come up during it, then we can schedule 3.4.5, > though I would consider 3.4.4 as the last stable release. Are any of the bug fixes for 3.4.4 urgent? I guess was thinking of a release date closer to 3.5.90, which isn't for another month yet (maybe August 13th). And then that would most likely be the last 3.4.x release as we'll be focused on 3.6.0 by that point. Nothing I see in the commit logs since 3.4.3 strikes me as particularly severe, but if you have certain fixes in mind you wish to get released sooner then I guess I'm up for it. 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] Cannot reconnect from EBackend-s like in Camel
On Mon, 2012-07-16 at 13:41 +0200, Milan Crha wrote: > there seems to be missing functionality in EBackend descendants to > reconnect on connection lost, like is possible in Camel. With Camel, > I check returned error for certain values and if the error is one of the > known for connection issues, then I just disconnect and the next attempt > for online operation reconnects the CamelService as its first action. Reading between the lines, it sounds like you're relying on the client to tell you when to connect. But EBackends are more autonomous now that they can authenticate on their own and no longer honor Evolution's artificial offline mode. A client's D-Bus connection to a backend and the backend's network connection to a remote host are orthogonal states. If the remote host is reachable, the backend can and should connect and authenticate on its own as needed without waiting for a client to tell it to. Check the network connection and re-connect if necessary as the first step in any D-Bus method invocation handler, and it seems like the same pattern as CamelService ought to work for EBackend as well. I'm probably oversimplifying a little. 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] Cannot reconnect from EBackend-s like in Camel
On Mon, 2012-07-16 at 17:58 +0200, Milan Crha wrote: > Hmm, do you mean to call things like e_book_backend_open() in a handler > of another method (that for the async book backend), thus passing in > EDataBook and opid dedicated to other operation on client's side? It > sounds a bit crazy, but I'll try that. :) That's not what I was suggesting but it gets at the issue I was trying to speak to. e_book_backend_open() is a client operation. Connecting to the remote server is presumably one of the things your open() handler does. Split that connection logic out so it can be called from other parts of the backend. It doesn't have to be tied to e_book_backend_open(). Hope that's clearer. 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 api for memo ?
On Fri, 2012-07-20 at 19:23 +0200, Pierre-Yves Luyten wrote: > Is there some API to play with evolution memos (vjournal) from another > application? > seems it's just .ics , but the VJOURNAL type is different than VTODO / > VEVENT Start with e_client_utils_new() and pass E_CLIENT_SOURCE_TYPE_MEMOS as the source type. http://developer.gnome.org/libedataserverui/unstable/libedataserverui-EClient-Utilities.html#e-client-utils-new That will return an ECalClient instance, giving you access to memo data. Further documentation: http://developer.gnome.org/libecal/unstable/ECalClient.html 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] Return back folder remember for Open/Save dialog
On Thu, 2012-07-26 at 14:08 +0200, Milan Crha wrote: > I asked for a string freeze break on gnome-3-4 branch in Evolution [1]. > I'll revert the removal, when/if they'll approve. I meant it when I said I would consider that a regression. ___ 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] Minor API break in libebackend
In working on the create/delete remote folder API for collection backends, I realized these backends are going to need something equivalent to e_source_registry_authenticate(). e_source_registry_server_queue_auth_session() is a "fire and forget" function in that the caller doesn't know when or even IF authentication succeeds. So I replaced it with the following functions: gboolean e_source_registry_server_authenticate_sync (ESourceRegistryServer *server, EAuthenticationSession *session, GCancellable *cancellable, GError **error); void e_source_registry_server_authenticate (ESourceRegistryServer *server, EAuthenticationSession *session, GCancellable *cancellable, GASyncReadyCallback callback, gpointer user_data); gboolean e_source_registry_server_authenticate_finish (ESourceRegistryServer *server, GAsyncResult *result, GError **error); I also pushed commits to EWS and MAPI to cope with the change. I figure since this new account-mgmt API hasn't seen a stable release yet, and since this particular change should only affect us, I'm not bothering with deprecations yet but I did bump the libebackend soname. Anyway, just a heads up. 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] New ECollectionBackend methods
I finally have the basic framework in place for creating and deleting folders on a remote server, with a working reference implementation in Evolution-EWS. The new APIs are documented here: http://mbarnes.fedorapeople.org/account-mgmt/docs/ I'll just give a brief overview. D-Bus Interfaces The core of the framework is two new optional D-Bus interfaces for data sources, similar to the existing "Removable" and "Writable" interfaces: org.gnome.evolution.dataserver.Source.RemoteCreatable Create() - creates a remote resource org.gnome.evolution.dataserver.Source.RemoteDeletable Delete() - deletes a remote resource The ESource class now has two new read-only boolean properties, "remote-creatable" and "remote-deletable", to indicate whether the ESource supports these capabilities. The EServerSideSource class, which is like a "super" ESource in the registry service, inherits these properties and makes then read/write. Setting either property to TRUE from within the registry service exports the interface over D-Bus, FALSE withdraws the interface. Client-Side Methods === On the client-side, the methods for these new interfaces are invoked directly through ESource. Both synchronous and asynchronous versions exist; the synchronous APIs look like this: gboolean e_source_remote_create_sync (ESource *source, ESource *scratch_source, GCancellable *cancellable, GError **error); gboolean e_source_remote_delete_sync (ESource *source, GCancellable *cancellable, GError **error); The corresponding boolean property must be TRUE or the method call will fail with a NOT_SUPPORTED error. Also the "scratch_source" argument is a description of the new resource to create. Typically a scratch source is assembled by a configuration editor like ESourceConfig. Note: I use the term "scratch source" throughout the API. This is meant to be analogous to scratch paper, or something temporary and disposable. Specifically it means the ESource has no internal GDBusObject linking it to any data source exported by the registry server. Server-Side Methods === On the server-side, EServerSideSource receives method invocations from clients and forwards them to an ECollectionBackend instance to actually do the remote creation and deletion. ECollectionBackendClass has some new synchronous and asynchronous virtual methods. This is done in the same style as Camel, where by default the asynchronous method calls the synchronous method from a thread, so subclasses need only implement the synchronous method. The synchronous virtual methods are: gboolean (*create_resource_sync) (ECollectionBackend *backend, ESource *source, GCancellable *cancellable, GError **error); gboolean (*delete_resource_sync) (ECollectionBackend *backend, ESource *source, GCancellable *cancellable, GError **error); Collection backends implementing these methods are expected to perform the remote operation first, and if successful then add/remove the data source to/from the ESourceRegistryServer. E-D-S clients will then see the data source appear or disappear. Policies Neither of these new interfaces are exported by default in the registry service, at least for now. Each collection backend has to export them explicitly if they wish to support the feature. Technically speaking, the interfaces can be exported on any data source, but the expectation is: - The data source representing the collection itself will export the "RemoteCreatable" interface. - Data sources created by the collection backend to proxy a resource on a groupware server will export the "RemoteDeletable" interface. With Evolution-EWS working, I'll be moving on to help Christian again with Evolution-Kolab next week. I assume Milan will handle Evo-MAPI. If there's time before 3.6, I think it would be cool to also support this in the Google and Yahoo! backends along with auto-discovery. Questions or comments, you know where to find me. 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 3.5.4 + Evolution-EWS JHbuild instant crash
On Sun, 2012-08-05 at 19:13 +0200, David Kubicek wrote: > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings > will not be saved or shared with other applications. > > (evolution:16535): e-data-server-WARNING **: > (e-source-registry.c:1008):source_registry_initable_init: runtime > check failed: (g_hash_table_size (registry->priv->sources) > 0) These messages suggest to me that jhbuild is not correctly set up to activate the necessary D-Bus services on which Evolution depends. I don't use jhbuild myself so I can't speak from experience, but I suggest following the setup steps in section 3.3.1 of: http://developer.gnome.org/jhbuild/stable/jhbuild-and-gnome.html.en In lieu of running an entire GNOME Desktop Environment under jhbuild, perhaps you could write a shell script similar to gnome-jhbuild-session as described in section 3.3.1 but have it run evolution instead. 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
[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
Re: [Evolution-hackers] Some minor Camel API breaks
On Mon, 2012-08-13 at 20:35 +0100, Philip Withnall wrote: > Is this documented anywhere (perhaps in an introductory section in the > EDS docs)? Does the mailing list count? ;) Good idea though. I guess I could document it in to the introductory parts of libedataserver and libebackend for starters. Not sure if the other E-D-S libraries fully adhere to it yet. 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
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] 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
[Evolution-hackers] Evolution 3.8 Planning
Few quick announcements: I started a new planning page on the wiki for Evolution 3.8 and seeded it with a few items. Would appreciate seeing it fleshed out a bit more. https://live.gnome.org/Evolution/Planning38 Milan and I discussed gnome-3-6 branches today. I'm ready to branch and begin 3.7 development now, but for the sake of translators we'll hold off until September 17 when GNOME 3.5.92 enters its hard code freeze. Also I'll be taking personal time off the latter half of this month, as will Milan I believe. So you may be hearing crickets in #evolution for couple weeks. I'll still have email and will get the 3.6.0 release out on time. Returning the first week of October. 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] Update on the composer port
On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote: > time to report on my progress in the composer port. I'd appreciate any > feedback and ideas. Thanks for the progress update! The class breakdown sounds good to me. I'm all for having lots of small classes with a well-defined purpose instead of some sprawling monolithic monstrosity that no one can grok. > EEditorSelection - represents current selection in the editor widget and > provides API to modify formatting of the selection. I keep asking > myself > if this could be merged to EEditorWidget, the main reason I haven't done > it yet is that e_editor_widget_set_bold() does not describe correctly > what the method does, unlike e_editor_selection_set_bold(). Also it > makes > the source files smaller. I hate long source files... :-) But if you > would > insist, I won't probably strictly object against merging it. +1 - Haven't looked at the code yet, but I think I might prefer it stay split out. GtkTreeView + GtkTreeSelection sets a precedent here. > EEditorDialog* - implementations of all the dialogs. I decided to throw away > the Glade file and single .c with implementation of all the dialogs > because it completely violates all principles of OOP and because I > have > to provide my own implementation of most of the actions in the dialogs > anyway, so the single signals file would be huuuge and ugly. +1 - Nowadays I think XML UI definitions are more trouble than they're worth. Plus GtkBuilder still has problems handling single-letter type name prefixes (e.g. "E"), so using our own custom widgets in our own XML files requires frequent ugly hacks. Not worth it. > EColorChooserWidget - this is a "subclass" of GtkColorChooserWidget. > Unfortunately API of the Gtk widget totally _SUCKS_, so it's more of a > hack. It's point is to make the color chooser to accept color by single > clicking it instead of double clicking. Perhaps the new GtkMenuButton in GTK+ 3.6 might help here? Perhaps you could subclass GtkMenuButton instead of GtkColorChooserWidget, but still embed GtkColorChooserWidget in your subclass. > EActionComboBox - I dragged this from /widgets/misc, because I need it in the > Editor, but libeeditor can't link against libemiscwidgets (it links > against libeeditor). Yeah, I'm toying with the idea of merging all these base libraries into one. libeutil + libemiscwidgets + libetimezonedialog + libetext + libetable + libemenus + ... there's just way too many already. Linking to all these shared libraries from layers higher up is a real PITA and probably increases our startup time since each shared library has to be loaded serially. > Behavior of the editor is almost identical to GtkhtmlEditor, except for HTML > mode -> Plain text switching. GtkhtmlEditor is simply switching renderers on > top of a single DOM document, but we can't do this with WebKit. I looked how > others do it and ended up with a "Switching to plain text will lose all > formatting, OK?" dialog. When user confirms, all formatting is removed and > plain text version is inserted back to the editor. Switching from Plain text > to HTML does not alter formatting in any way (because there is no formatting > to alter :) I'm sure we'll get some grumbling about that, but I can live with it. > The "Undo"/"Redo" actions might be slightly broken/inconsistent with > Gtkhtml as well, because I don't have access to the action stack of > WebKit, and WebKit records only some actions. I'm using these actions I > know that WebKit records to do most of the formatting/DOM manipulation, > but on some places it's just not possible to get the right result this > way. That's a little more concerning. Maybe we can work with the WebKit guys to expose more of the undo framework? > During the port I've run into at least one "unportable" thing - WebKit > does not provide any means to change color of the underline of > misspelled words, so I'll probably have to remove this feature (I don't > see much use in it anyway). I have no problem with that. The underline color for misspelled words should really be defined by themes anyway. > Finally, Milan had some objections against the "EEditor" prefix, feel > free to discuss a better alternative. No strong opinion here. I can live with EEditor. > I'll write a blog post when the port is merged to master. I'd like to > do the merge as soon as possible, because my time to continue working > on it will be more and more limited during the semester, so the sooner > you can test and report back the better. Feel free to start testing > already (you can use the e- editor-test utility to test the editor > itself). If you want to report bugs, please use evolution[composer] and > evolution[webkit] whiteboards. I plan to create gnome-3-6 branches after the 3.5.92 release later this month. We can merge immediate
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
[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] 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
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] 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] 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] [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] 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] UI interaction from book/calendar backends
On Thu, 2012-11-22 at 09:13 +0100, Milan Crha wrote: > What I have on mind is something what Camel already provides [1], the > camel_session_alert_user() function, which basically provides generic > dialog facility for asking users. The question is where to put such > functionality for book/calendar backends, because they are > client-oriented, not session oriented like providers in Camel. It would > not work to teach each client, and also user of the client, about this > interaction, thus I think the right place is evolution-source-registry, > which already requires gtk. This can be hidden on the backend side by > some base class function e_backend_alert_user(), and where it'll pass > the data is up to it. Note this is not used for random errors, for that > is other e_cal/book_backend_notify_error() function, which will be left. Actually I don't think evolution-source-registry requires GTK+. If it's the password dialog you're thinking of, we only link to gcr-base-3 which speaks via D-Bus to the process actually showing the password dialog. I'm not sure if evolution-source-registry is ultimately the right place for user interfaces, but I can't think of a better solution at present. I have a few requests, though: 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. 2) Create a new well-known bus name for this. Perhaps something like org.gnome.evolution.dataserver.Prompts 3) Come up with a corresponding D-Bus interface, put the XML spec in the "private" directory and let gdbus-codegen create the GDBus glue. The idea here is to keep the functionality relocatable, both for the benefit of Tizen and for ourselves if we think of a better place for this stuff 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
[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 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
