Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote: > Hello, > this is a heads up that the evolution-data-server, evolution, > evolution-ews and evolution-mapi products will switch from Autotools to > CMake for the 3.23.1 release. Out of interest, why? Philip signature.asc Description: This is a digitally signed message part ___ 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] vCard test suite
On Tue, 2016-04-05 at 22:52 +0200, Milan Crha wrote: > On Tue, 2016-04-05 at 20:44 +0200, Ángel González wrote: > > > > On 2016-04-05 at 08:52 +0100, Philip Withnall wrote: > > > > > > I don’t think I explained clearly enough, sorry. All three > > > options > > > are > > > proposing to keep vcard-test-suite as a separate project, which > > > EDS > > > depends on in some way (either as a test-time dependency, a git > > > submodule, or a build-time dependency). > > I don't think it should be a build-time dependency. If the > > dependency > > is not fulfilled, you should still be able to build and run eds > > (except > > for running those tests, of course). > > > Hi, > I agree with Ángel, build time dependency is out of question. Also > because soft dependencies are easy to overlook, thus one might easily > not even notice the new test suit. > > I'm not sure how you'd like to have done the test-time dependency. If > the files would not be available, will the whole test suit be > skipped, > or the test will fail with an error? The first option is similar to > build time dependency (being it a soft dependency). The second option > might be a bit limiting, no? It would have to be a soft dependency; as you say, a hard dependency is out of the question. With the installed-tests approach, the EDS vCard test would be skipped if the vCards were not installed. > That lefts us with a git submodule. What is the difference between > the > git submodule and direct inclusion in the sources? With a git submodule, the vCards can be re-used in other projects while being updated from a central repository, rather than diverging between all the projects. > If you want to cover > more than vCard tests for the evolution-data-server (like testing > also > other vCard parsers, from other libraries), then it seems to me that > the cleanest solution would be to provide installed-tests from the > git > repo as you have it, just define different "targets". I mean, I miss > a > gain in the inclusion of the project as a git submodule in the > evolution-data-server. It's possible I'm overlooking something > though. I’m not sure what you mean. If the vcard-test-suite project builds and installs installed-tests for EDS (and other projects), what’s going to pull those installed tests into a system? Nobody is going to package vcard-test-suite for its own sake. And I wouldn’t want it to grow dependencies on every vCard parser library out there just so that it can build the tests itself. Philip signature.asc Description: This is a digitally signed message part ___ 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] vCard test suite
Hey, On Mon, 2016-04-04 at 10:08 +0200, Milan Crha wrote: > On Sun, 2016-04-03 at 22:13 +0100, Philip Withnall wrote: > > > > How would it be best to include this in the EDS test suite? The > > options > > I see are: > > • Install the vCards on the system in the installed-tests prefix, > > for > > use by unit tests installed by EDS. > > • Import them as a git submodule into EDS. > > • Keep vcard-test-suite separate and have it install its own unit > > test > > for EDS[1]. > > > > I think the first option might be the best, but I would appreciate > > others’ input. > > > Hi, > if the Collabora is fine to copy/move the data and the code in the > evolution-data-server sources, then I do not see any issue with it. I don’t think I explained clearly enough, sorry. All three options are proposing to keep vcard-test-suite as a separate project, which EDS depends on in some way (either as a test-time dependency, a git submodule, or a build-time dependency). > I would also prefer to make it part of the installed-tests for the > evolution-data-server, together with the binary which will process > all > those files (install data and do not use them looks incorrect). That seems like a good goal, regardless of which method we choose to do it. Philip signature.asc Description: This is a digitally signed message part ___ 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] vCard test suite
Hi all, A while ago, Alex Shtyrov created a test suite of vCards (invalid and valid) for testing EVCard and other vCard parsers. The intention was that it would be a project-neutral source of vCard examples and test vectors. https://gitlab.com/pwithnall/vcard-test-suite How would it be best to include this in the EDS test suite? The options I see are: • Install the vCards on the system in the installed-tests prefix, for use by unit tests installed by EDS. • Import them as a git submodule into EDS. • Keep vcard-test-suite separate and have it install its own unit test for EDS[1]. I think the first option might be the best, but I would appreciate others’ input. The vcard-test-suite already includes all the vCard test vectors we could find in the existing EDS unit tests. Philip [1]: https://gitlab.com/pwithnall/vcard-test-suite/blob/master/utilitie s/eds-vcard-tester.c signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-data-server: WebDAV] Get list of all calendars for user
Hey, On Thu, 2015-05-14 at 13:31 +0200, Alexis Maiquez Murcia wrote: I'm actually helping to develop the Maya calendar project ( https://launchpad.net/maya ). Maya is the default calendar that comes with ElementaryOS. We have already implemented support for individual WebDAV-based calendars (it was fairly easy using evolution-data-server and libedataserver) but is not so easy with multiple-calendar users AND google users. I want users to be able to select what calendars they wants to sync and add support to sync google calendar in the same way (multiple-or-single calendar syncs). So my two questions are: -Is there any way to retrieve a calendars list with libedataserver for WebDAV-based users? -Is there any specific way to connect to Google Calendar through libedataserver and sync those calendars too? (the WebDAV method is considered insecure by google) It’s probably worth mentioning that libgdata[1] can list your Google Calendars, and has recently been upgraded to support v3 of the Google API (the latest). *However*, if you can achieve what you want with CalDAV and the methods given by Milan, I would strongly suggest going with that. It allows for more code re-use, and the EDS CalDAV code is more mature than libgdata. In any case, please report bugs (to EDS[2] or libgdata[3]) for any missing features you require, so that the amount of code we can share is maximised. :-) Philip [1]: https://wiki.gnome.org/Projects/libgdata [2]: https://bugzilla.gnome.org/enter_bug.cgi?product=evolution-data-server [3]: https://bugzilla.gnome.org/enter_bug.cgi?product=libgdata signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?
Hey, If you have some output showing the errors gobject-introspection gives you when you run it on libical, I might be able to help you fix them. Philip On Wed, 2014-05-14 at 20:13 -0400, Miao Yu wrote: Hi, If I am not wrong, it is because the gobject-introspection has a hard time in introspecting a third-party types, as those in libical. For now, the only solution I can come up with is, as Milan said, to create a proxy type for every type of libical which is used in EDS. After that, I have to replace the libical types with the newly-created introspectable proxy type in the API, which causes the disaster. And this solution is, in nature, to write a introspectable wrapper for the libical library. So that's why Milan want to put this under GObject so that other applications can also use it instead of the libical. And your solution is a nice way to fix that. Actually the focus can also be put on the gobject-introspection. And gobject-introspection can work with libical. Due to lack of experience, I cannot say which one is better for now. But they can work to the same end. But if we focus on the gobject-introspection, the introspection is not more focusing solely on the gobjects since libical is a third-party library. Thank you. William Yu -Original Message- From: Philip Withnall phi...@tecnocode.co.uk To: Milan Crha mc...@redhat.com Cc: evolution-hackers evolution-hackers@gnome.org; will.yu will...@aol.com Sent: Wed, May 14, 2014 1:16 pm Subject: Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed? On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote: The current problem is libical, its icalcomponent, enums and all other structures. I thought that we will be able to introspect this with simple boxed types, but it doesn't seem to be possible, thus the only option I can see is to massively change API of the calendar and define proxies for libical structures and enums. These proxies would be fully GObject-based, which might be a plus, I hope. What exactly is the problem with introspecting libical? If it's a fixable problem with gobject-introspection, I suspect it would be less work (and a better overall outcome) if time were put into fixing gobject-introspection so that libical *can* be introspected; rather than putting more work into a wrapper library which will increase memory overheads and require maintenance. Philip signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS Documentation Effort
On Mon, 2013-11-04 at 15:18 +0900, Tristan Van Berkom wrote: I'm starting a little documentation effort this month for the user facing apis in evolution data server. The scope of this project will touch on the libedataserver, libebook, libebook-contacts and libecal APIs (afforded the time I might be able to dig a little deeper into the server side libedata-book / libedata-cal APIs but strictly speaking we want to focus on user facing APIs). Just so (hopefully) work doesn’t end up being duplicated, I just spent an hour expanding the documentation for EVCard. Patches are here: https://bugzilla.gnome.org/show_bug.cgi?id=712323 More examples could be added to it, but I think it’s now in much better shape than it was. (And, entirely selfishly, I won’t have to keep referring to the code for EVCard any more.) Philip signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Testing EEwsConnection's API
On Thu, 2013-10-10 at 11:24 +0200, Fabiano Fidencio wrote: Please, take a look into: http://blog.fidencio.org/2013/10/evolution-ews-testing-eewsconnections.html Yay! Nice work. \o/ Philip signature.asc Description: This is a digitally signed message part ___ 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 14:56 -0400, Matthew Barnes wrote: 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: Ah, I didn’t realise you were also using ‘_dup_’. Explained like that, your convention makes perfect sense. :-) Is this documented anywhere (perhaps in an introductory section in the EDS docs)? Philip signature.asc Description: This is a digitally signed message part ___ 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 Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote: Moreover, there's a GSoC project (see https://live.gnome.org/SummerOfCode2012/Ideas) for a backend cache infrastructure (the Ideas page still outlines a Contact cache - is this up-to-date?). Via KolabMailSideCache and KolabMailInfoDb, evolution-kolab already implements an offline cache for both, contacts and calendar types. Albeit being somewhat Kolab-centric at present, this is a working offline cache infrastructure already existing, which could be generalized and/or cannibalized for a new cache usable by all backends (including evolution-kolab). I'd be happy to use a generalized backend cache in evolution-kolab, rather than having each backend implement its own cache, provided evolution-kolab's needs (like being able to store binary blobs) are satisfied. Feel free to ask questions - I'm here to answer them as much as I can. Unfortunately, there are no GSoC students working on that idea — none of them showed any interest. :-( Milan did some design work on an API for the cache, though I've misplaced it at the moment. I don't know how this fits in with Kolab's current cache API, but code reuse is always good. I will hopefully have some time to work on this in a month or two, if nobody else has done so by then. My time is really limited up until mid-June though. Philip Kind regards, Christian ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ 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 13:11 -0400, Matthew Barnes wrote: 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. 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. 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. 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. 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). Philip 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 signature.asc Description: This is a
Re: [Evolution-hackers] Evolution-data-server offline handling
On Fri, 2012-02-03 at 11:13 -0500, Matthew Barnes wrote: 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. 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?) Philip 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 signature.asc Description: This is a digitally signed message part ___ 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] better deleting for GMail
On Sun, 2011-12-25 at 14:55 +0800, Mike Manilone wrote: Hi list, The default behavior of deleting is moving it to /Trash folder, but if you're using GMail [with IMAP?], you cannot remove them at all. Then I tried to move them to [Gmail]/Trash. It's ok! You can change the ‘Special Folders’ preferences for the account in the account settings dialogue, where you should be able to change the trash folder to [Gmail]/Trash. That works for me. Note that it does then break the behaviour where you can press ‘delete’ on a message in your inbox to archive it (rather than trash it). So, hackers, why don't add a configuration entry about deleting folder? Then the behavior of deleting is as good as thunderbird. I don't know if this is already the case, but this seems like something which should be done automatically if you set your GMail account up through GOA. Philip ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ 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] Google Tasks in EDS
Hey, On Thu, 2011-09-01 at 07:58 +0100, Ross Burton wrote: Hi, Is anyone working on a Google Tasks backend for EDS? Annoyingly Google doesn't expose Tasks over CalDAV but they do have a custom HTTP/OAuth/REST API that shouldn't be that hard to access from librest. I don't know if anyone's working on one, but there's a bug report about it here: https://bugzilla.gnome.org/show_bug.cgi?id=652132 Any such backend would be best using libgdata to do the protocol-level work, since as you say, Tasks aren't exposed over CalDAV. This will require a new service to be added in libgdata: https://bugzilla.gnome.org/show_bug.cgi?id=657539 I hope to be able to fix that bug in libgdata next cycle. (Version 0.12 is targeted at GNOME 3.4.) Philip Ross ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ 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] Google Tasks in EDS
On Thu, 2011-09-01 at 08:26 +0100, Ross Burton wrote: On 1 September 2011 08:15, Philip Withnall phi...@tecnocode.co.uk wrote: Any such backend would be best using libgdata to do the protocol-level work, since as you say, Tasks aren't exposed over CalDAV. This will require a new service to be added in libgdata: As far as I am aware the Tasks API uses a custom JSON protocol[1], whereas libgdata implements their GData extensions to Atom, which is why I was suggesting json-glib+librest. That's entirely correct. However, I've been thinking about extending libgdata to support JSON-based services in addition to the ‘normal’ Atom-based services for a little while now; since Google seem to be moving in that direction. I think it should be possible, and would be a better approach than writing things from scratch using json-glib. (An approach which, for example, would end up duplicating the non-trivial load of authentication code already present in libgdata.) The code in libgdata should definitely make use of json-glib, though. Philip Ross [1] http://code.google.com/apis/tasks/v1/reference.html#resource_tasks signature.asc Description: This is a digitally signed message part ___ 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] GOA Integration (was: New 'eclient' branch in eds)
On Thu, 2011-06-30 at 13:45 -0400, Matthew Barnes wrote: On Fri, 2011-06-10 at 17:02 +0100, Philip Withnall wrote: On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: Google Calendars have me stumped, however, since we defer to our standard CalDAV backend which authenticates with stored passwords from the keyring. I'm not sure how to slip in OAuth integration for this one special case. Hmm. I guess either the standard CalDAV backend could be modified to use OAuth if the domain name matches “google.com” (or whatever); or the Google Calendar backend could be resurrected with special authentication code, but sharing the CalDAV code with the normal CalDAV backend. Just to follow up on this... I wrote a custom SoupAuth class for OAuth. Instead of calling soup_auth_authenticate() on it, you would instead call a different function that takes the consumer key, consumer secret, token and token secret strings as parameters, which the GNOME Online Accounts API provides. That's a neat idea. Perhaps it would be worthwhile putting this in libsoup proper so that we have a common place for OAuth implementations. It does seem to be the right place. Turns out it was all for naught, because I later realized Google's CalDAV interface currently only supports Basic HTTP authentication. Haven't seen any indication that OAuth support is forthcoming. That's unfortunate. Google don't seem to really love the Calendar APIs or CalDAV interface much. :-( Philip So that kinda sucks; users will still have to enter a password to access the calendar even if they have a valid access token. But it does mean GOA integration in Evolution is pretty much done for now and I can get back to other priorities. I'll keep my little SoupAuth class around in case the situation with Google's CalDAV interface changes. signature.asc Description: This is a digitally signed message part ___ 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] GOA Integration (was: New 'eclient' branch in eds)
On Fri, 2011-06-10 at 17:02 +0100, Philip Withnall wrote: On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: On Thu, 2011-06-09 at 21:56 +0100, Philip Withnall wrote: I guess this involves updating the Google Contacts address book backend to use GOA's OAuth 1.0 magic. I've recently updated libgdata to be able to cope with OAuth, and I've got an (untested) patch to e-d-s to update it to use libgdata's shiny new authorisation API. Over the next few days I intend to test it properly and fix it up. I hope this fits in well with what you've been conscripted to do re. GOA. Having just started on it this week, so far I'm mostly just concerned with keeping Evolution synchronized with any Google online accounts. But yeah, I was hoping libgdata would make things magically work for address book authentication. And I think I have a handle on the mail side -- just need to extend our CamelSASL framework to handle XOAUTH from outside of Camel. libgdata's new API implements authentication/authorisation using a GDataAuthorizer interface[1]. At the moment, libgdata has implementations of this interface for ClientLogin (Google's old username/password auth system) and OAuth 1.0. The patch I've got for e-d-s converts the Google Contacts address book backend to use libgdata's ClientLogin authoriser to keep up with libgdata's rampant API breaks. Since I've now released libgdata 0.9.0, here are the patches for evo and e-d-s to port them to the new authentication mechanism (but still using username/password): • https://bugzilla.gnome.org/show_bug.cgi?id=652392 • https://bugzilla.gnome.org/show_bug.cgi?id=652394 Philip What I've been discussing with davidz is the implementation of some sort of GnomeOnlineAccountsAuthorizer class (in e-d-s' Google Contacts backend?) which implements GDataAuthorizer and just sticks GOA's OAuth 1.0 tokens onto every request. This would work for Google Contacts. Google Calendars have me stumped, however, since we defer to our standard CalDAV backend which authenticates with stored passwords from the keyring. I'm not sure how to slip in OAuth integration for this one special case. Hmm. I guess either the standard CalDAV backend could be modified to use OAuth if the domain name matches “google.com” (or whatever); or the Google Calendar backend could be resurrected with special authentication code, but sharing the CalDAV code with the normal CalDAV backend. Philip [1]: http://git.gnome.org/browse/libgdata/tree/gdata/gdata-authorizer.h I'm open to suggestions if you have any. signature.asc Description: This is a digitally signed message part ___ 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] GOA Integration (was: New 'eclient' branch in eds)
On Thu, 2011-06-09 at 17:24 -0400, Matthew Barnes wrote: On Thu, 2011-06-09 at 21:56 +0100, Philip Withnall wrote: I guess this involves updating the Google Contacts address book backend to use GOA's OAuth 1.0 magic. I've recently updated libgdata to be able to cope with OAuth, and I've got an (untested) patch to e-d-s to update it to use libgdata's shiny new authorisation API. Over the next few days I intend to test it properly and fix it up. I hope this fits in well with what you've been conscripted to do re. GOA. Having just started on it this week, so far I'm mostly just concerned with keeping Evolution synchronized with any Google online accounts. But yeah, I was hoping libgdata would make things magically work for address book authentication. And I think I have a handle on the mail side -- just need to extend our CamelSASL framework to handle XOAUTH from outside of Camel. libgdata's new API implements authentication/authorisation using a GDataAuthorizer interface[1]. At the moment, libgdata has implementations of this interface for ClientLogin (Google's old username/password auth system) and OAuth 1.0. The patch I've got for e-d-s converts the Google Contacts address book backend to use libgdata's ClientLogin authoriser to keep up with libgdata's rampant API breaks. What I've been discussing with davidz is the implementation of some sort of GnomeOnlineAccountsAuthorizer class (in e-d-s' Google Contacts backend?) which implements GDataAuthorizer and just sticks GOA's OAuth 1.0 tokens onto every request. This would work for Google Contacts. Google Calendars have me stumped, however, since we defer to our standard CalDAV backend which authenticates with stored passwords from the keyring. I'm not sure how to slip in OAuth integration for this one special case. Hmm. I guess either the standard CalDAV backend could be modified to use OAuth if the domain name matches “google.com” (or whatever); or the Google Calendar backend could be resurrected with special authentication code, but sharing the CalDAV code with the normal CalDAV backend. Philip [1]: http://git.gnome.org/browse/libgdata/tree/gdata/gdata-authorizer.h I'm open to suggestions if you have any. signature.asc Description: This is a digitally signed message part ___ 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] New 'eclient' branch in eds
Hey, I haven't had a chance to look at it all in detail, but two things strike me from a quick glance: • If we're following the GIO async pattern, why do the e_data_book_respond_*() functions still exist? • Please, please, please add some documentation to the new EDataBook. Trying to understand how the old one was supposed to function was a nightmare, and I would hope that the same mistake isn't repeated with the shiny new version. Thanks for working on this (and porting the Google Contacts backend!). Philip On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote: Hi, I just created a new branch 'eclient' in eds [1] where is added my work on the new API which will deprecate EBook/ECal. It is following glib/gio async pattern and, I believe, makes things more coherent. This change, apart of other things, influences also backends, as I added GCancellable to each virtual function which deserved it, made ECalBackend authentication process similar to that used on EBookBackend-s (with authenticate_user function), and I dropped unused and/or unnecessary virtual functions from backends as well (mostly from ECalBackend). The GDBus interface functions were also completely rewritten, for better readability, I believe (and hope). Please have a look and comment here, before I'll commit this to git master, which I would like to do before the first 3.1 release of eds, thus all other descendants of backends will have enough time to change their code appropriately. The next step, after such commit, will be to slowly adapt evolution itself, with which I would prefer to wait till Matt's account management changes will land, definitely on places which are interleaving, because I would like to avoid most of the pain when merging changes, unless we'll make other deal on this. Bye, Milan [1] http://git.gnome.org/browse/evolution-data-server/log/?h=eclient ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi, On Mon, 2010-06-07 at 17:31 +0200, Christian Hilberg wrote: Hi there, while the project setup process is going on, I've had a look again at suitable testframeworks. Unfortunately, many unit test frameworks for the C language appear to be abandoned. On Wednesday 26 May 2010 at 12:18:04 you wrote: Hi Christian, On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: We'll check that out with other Gnome projects. It may take some more research on the project itself before we know how to actually accomplish the testing stuff. My thoughts atm tend towards cunit/expect and/or the GLib testing framework. I think the consensus from 10k feet is something like: any unit tests are good ! wow, you have unit tests ? cool ! :-) so it is unlikely that anyone is going to come and gripe about your unit testing framework per-se; of course people moan about new dependencies - so re-using the gtestutils.[ch] would be good if it's easy, and of course most preferably hooking it all up to 'make check' is best, as Matthew said. Using the GLib framework for testing seemed to be a natural choice, until I dug through the mail archives and found that it (a) is neither nice to set up for projects outside GLib/GTK istelf [1] (latest information I found on the issue dates back from 2008) (b) nor is it well-documented and finally (c) does not seem to be in wide use outside GTK and GLib itself. I've used the GLib test framework extensively for one of my projects, libgdata[1], and it's fine to use outside of the GLib/GTK+ trees. Several GNOME projects make use of it (more than other test frameworks in my experience). The GLib test framework can fork() tests using g_test_trap_fork() and friends. Regards, Philip [1]: http://live.gnome.org/libgdata Other testframeworks I've checked (like CUnit, cUnit, RCunit, CuTest, Embedded Unit) did not receive project updates since 2006 (some since 2003), so I assume they're dead. Setting aside commercial frameworks, which are no option unless they're explicitly FLOSSed, I'm left with Unity[2], Cutter[3] and Check[4]. Cutter depends on GLib = 2.16, so I assume it uses the GLib testing framework internally and I found references to it in some GTK/GLib context. What's more, Cutter has support for GLib types (just read in the docs, no practical experience as yet), which would be helpful in our case. Check seems to be in wider usage. It fork()s a new process for each unit test it runs, which seems to be a good thing to do to protect the framework's address space from runaway test cases, unless you're so much restricted (as in some embedded environments), that you cannot fork() - but there is no point in running E-D-S in such an environment, anyway. Unity (also) targets embedded contexts and the Sourceforge project is alive (latest release 2009-12-07, current checkins to the SF repo). There does not seem to be much of a documentation online. Long story short, as for now I'm down to either Cutter or Check to use. I'd like to know if you prefer one over the other, which I would like to take into account for my proposal to the other project members regarding the testframework to use. Best regards and aTdHvAaNnKcSe for any insights, Christian [1] http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html [2] http://sourceforge.net/apps/trac/embunity/wiki [3] http://cutter.sourceforge.net/ [4] http://check.sourceforge.net/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ 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] Failing to configure libgdata from git master?
On Wed, 2010-04-21 at 10:42 -0500, C de-Avillez wrote: On Mon, 2010-04-19 at 16:43 -0400, Paul Smith wrote: snip/ Checking for required M4 macros... introspection.m4 not found ***Error***: some autoconf macros required to build gdata were not found in your aclocal path, or some forbidden macros were found. Perhaps you need to adjust your ACLOCAL_FLAGS? Looking around I found copies of introspection.m4 in the git source trees for atk and gtk+. However, neither of those packages install that file as part of their normal builds. Hi Paul, At least for Ubuntu Lucid, the macro is provided by the gobject-introspection package -- so, I guess we may need a new dependency there. By the way, if you install 'apt-file', you can search for a package containing a file (even if the package is not installed) by: apt-file search filename This is how I found it. On the other hand, when I try to make it, I get the following error: checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf checking whether to build gtk-doc documentation... no configure: creating ./config.status config.status: creating Makefile config.status: creating libgdata.pc config.status: creating gdata/tests/Makefile config.status: creating po/Makefile.in config.status: creating docs/Makefile config.status: creating docs/reference/Makefile config.status: creating docs/reference/version.xml config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands config.status: executing default-1 commands config.status: executing po/stamp-it commands Now type `make' to compile gdata Running build for libgdata make[1]: Entering directory `/src/buildd/evolution/obj/libgdata' make all-recursive make[2]: Entering directory `/src/buildd/evolution/obj/libgdata' Making all in . make[3]: Entering directory `/src/buildd/evolution/obj/libgdata' make[3]: *** No rule to make target `../../libgdata/gdata/gdata-marshal.h', needed by `gdata/gdata-marshal.c'. Stop. make[3]: Leaving directory `/src/buildd/evolution/obj/libgdata' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/src/buildd/evolution/obj/libgdata' make[1]: *** [all] Error 2 make[1]: Leaving directory `/src/buildd/evolution/obj/libgdata' make: *** [.stamp/libgdata.build] Error 2 That's https://bugzilla.gnome.org/show_bug.cgi?id=616222. Philip Regards, ..C.. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ 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] Failing to configure libgdata from git master?
Hi, On Mon, 2010-04-19 at 16:43 -0400, Paul Smith wrote: Hi Philip; all the docs I saw for libgdata list just your address as a contact; if there's a mailing list or similar you'd like me to CC please let me know. I'm the only maintainer at the moment, so e-mailing this address is fine. (There's no libgdata mailing list.) I maintain a makefile that allows people to build Evolution from the latest git sources along with a significant chunk of other Gnome (and some non-Gnome) libraries that Evo also uses. One of the new requirements for the latest Evo git master is libgdata. It requires 0.6.3 or above, but the version that comes on my Ubuntu (9.04) box is 0.4.0, so too old. So, I've added support for building libgdata from git to my makefile... or started to. Building libgdata from git won't work, since there are a number of API and ABI breakages in master which will probably cause the e-d-s build to choke (though Evolution itself should be OK). I'd advise you to use the libgdata-0-6 branch. The checkout of the git code works fine but the configure command fails right away: *snip* Looking around I found copies of introspection.m4 in the git source trees for atk and gtk+. However, neither of those packages install that file as part of their normal builds. I think if you need this you should be including it in the sources of libgdata, or else maybe file a bug against gtk+ or similar asking them to install it during their builds? introspection.m4 should be provided by gobject-introspection, and I believe their official advice is not to distribute it in individual packages' source trees. Regards, Philip I worked around this locally by manually copying introspection.m4 from gtk+ into my target $prefix/share/aclocal, where autoconf found it. Thanks! signature.asc Description: This is a digitally signed message part ___ 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] Problems with Migration from 2.28.4 to 2.30 (master): calendar, task, memo not there
On Sat, 2010-03-13 at 14:35 -0500, Matthew Barnes wrote: On Fri, 2010-03-12 at 20:13 +0100, Thomas Mittelstaedt wrote: Just tried the latest git version (master). Building and compiling went relatively smooth. After following advice at http://www.mail-archive.com/evolution-hackers@gnome.org/msg03339.html the app came up okay. Unfortunately, when I opened the calendar, the different calendars would show up in the list to the left, but no data is displayed, even though the ics files clearly exist and contain data. When I tried to import one of those ics files the app crashed. What is the correct way to migrate from 2.28.x to the latest version? The address book and calendar backend processes are now D-Bus services instead of Bonobo servers in 2.30. If you've installed your builds into a non-standard prefix (i.e. something other than /usr), then D-Bus probably doesn't know how to start the services and thus can't provide any data to Evolution. And Evolution isn't equipped to handle that gracefully at the moment, which would likely explain the crashes. If that's the case then you'll need to configure D-Bus so it can find the .service files you installed. Create a /etc/dbus-1/session-local.conf file and populate it with: !DOCTYPE busconfig PUBLIC -//freedesktop//DTD D-BUS Bus Configuration 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd; busconfig servicedir/path/to/your/dbus-1/services/servicedir /busconfig Using an appropriate servicedir path for your particular setup. It would be useful if this was put in e-d-s' HACKING file (or similar) somewhere, since it's necessary for pretty much anyone who uses jhbuild to get e-d-s working. Philip You may need to log out and log in again for the new settings to take effect. (There's probably a way to do it without having to log out, but I'm not sure how.) Hope this helps, Matthew Barnes ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libgdata
On Mon, 2009-02-23 at 13:16 +0530, Chenthill wrote: On Sun, 2009-02-22 at 22:44 +, Philip Withnall wrote: Hi, I've been writing a full C library to access GData-based services, with the aims of: 1. rewriting Totem's YouTube plugin in C, 2. providing a useful desktop-wide way to access Google services, and 3. merging it with the libgdata and libgdata-google in e-d-s' tree, such that e-d-s depends on a proper, external library for its Google Calendar server backend. I'm getting to the stage where it would be possible to merge with the code in e-d-s' libgdata, but obviously this can only happen if the authors of e-d-s' libgdata agree and think this is a good idea. If you want to keep your libgdata separate and untouched, I'm happy to go along with that, although it seems like a missed opportunity as regards reducing code duplication across the desktop. The code is currently on Github[1], with the beginnings of Google Calendar support in a branch[2], but the eventual aim is to move it to GNOME SVN (or git, or whatever) and move it into the desktop platform. EDS provides data primarily for mail,contacts, calendar, memos and tasks. It would be good to move the libgdata code from EDS into a separate project, say 'gdata-c' in order provide entire set of Google services. You can probably create a new project in svn.gnome.org for the same. I'll take that as a yes then. :) I'll continue hacking away at it, move it into GNOME SVN and see if I can get a patch together to migrate e-d-s to the new library. Regards, Philip - Chenthill. Regards, Philip Withnall [1]: http://github.com/pwithnall/libgdata/tree/master [2]: http://github.com/pwithnall/libgdata/tree/calendar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] libgdata
Hi, I've been writing a full C library to access GData-based services, with the aims of: 1. rewriting Totem's YouTube plugin in C, 2. providing a useful desktop-wide way to access Google services, and 3. merging it with the libgdata and libgdata-google in e-d-s' tree, such that e-d-s depends on a proper, external library for its Google Calendar server backend. I'm getting to the stage where it would be possible to merge with the code in e-d-s' libgdata, but obviously this can only happen if the authors of e-d-s' libgdata agree and think this is a good idea. If you want to keep your libgdata separate and untouched, I'm happy to go along with that, although it seems like a missed opportunity as regards reducing code duplication across the desktop. The code is currently on Github[1], with the beginnings of Google Calendar support in a branch[2], but the eventual aim is to move it to GNOME SVN (or git, or whatever) and move it into the desktop platform. Regards, Philip Withnall [1]: http://github.com/pwithnall/libgdata/tree/master [2]: http://github.com/pwithnall/libgdata/tree/calendar signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution: Taking forward...
Permission granted to relicence my code (committed as [EMAIL PROTECTED] or [EMAIL PROTECTED]). Thanks, Philip On Fri, 2008-07-11 at 04:21 -0600, Srinivasa Ragavan wrote: Hello guys, We have had a set of problems that we are carrying around for some time like : * Copyright assignments, which is not the best way looking for the future of Evolution. It sucks and sort of limits contributions to Evolution and we wanted to drop it. * The current licensing incompatibility issues of Evolution with Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the new mapi based connector being developed for Exchange 2007. So here is the plan : * Drop Evolution copyright assignments and make it really easy to contribute to Evolution * Move Evolution licensing to LGPL v2 and LGPL v3 to let us re-use the code more easily around the platform. This also moves us closer to Thunderbird's MPL/LGPL model. We think this is good for Evolution and (of course) we continue to invest in Evolution. We are also working to ensure we have the rights to re-license all of the code. We will do the licensing/header changes as we audit the code ownership situation. It would be really helpful if you can post a public/explicit mail with permissions to do it, or code pointers - if you think you wrote a piece of Evolution code object. We are really excited about this and we feel this would really help Evolution a lot. We need your support now for making this change and to take Evolution to great heights. Thanks for your contributions and support. -Srini. ___ desktop-devel-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
