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
[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] libgdata
On Mon, 2009-02-23 at 13:16 +0530, Chenthill wrote: > On Sun, 2009-02-22 at 22:44 +0000, 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
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: > > "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" > "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> > > /path/to/your/dbus-1/services > > > Using an appropriate 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] 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] 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: > > > > > 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 > > 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] 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] 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] 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] 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-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] 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 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] 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] 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] PIM server synchronization and Evolution online/offline state
On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: > Hi Milan, > > thanks a lot for joining us and for writing the nice summary! > This is much appreciated. If the mail thread becomes too long > and overly complicated, it may make sense to drop the findings > into a wiki page and work it out from there. > > First of all, no, the things discussed here are not going to be > easy, and it raises the question what Evolution actually wants > to be. Does it want to be a fully offline-capable PIM/groupware > client? That means, does it want to support backends which are or > strive to be? > > Which is the long-term vision for Evolution in this regard? > > > Am Mittwoch 04 April 2012, um 12:24:58 schrieb Milan Crha: > > On Tue, 2012-04-03 at 13:33 -0400, Matthew Barnes wrote: > > > On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote: > > > > Just rough thinking, nothing elaborate as yet - I'll be meditating > > > > this. :) > > > > > > Rough thinking here too. I'll let it simmer. > > > > Hi, > > this thread is getting quite complicated, and I confess I'm rather lost > > here (the final outcome should be clear, right). But to summarize which > > things are discussed here a bit (or better those I understood): > > > > a) Add an explicit method to synchronize local changes into the server > > b) Add some mechanism to ask user for conflict resolution during a) > > c) Tell backend to work in "offline mode" - do no network operations > > d) Notify client about current "offline mode" being used by the backend > > That pretty much sums it up. > > > -- > > > > ad a) There is agreed about the method addition, and I agree too. Maybe > > a different method prototype would be used (more parameters, see below). > > I suppose, you still tries to write the changes to the server as soon as > > possible, when in online mode, right? It makes sense, I'm only checking. > > Trying to bulk-sync as soon as network comes back online may interfere > with the user's planned workflow (just reading latest mails on a shaky > line), so I would suggest to either leave that to the user (by pressing > the sync button), or to provide a config option. The latter could also > be done on a per-backend basis. > > > -- > > > > ad b) This is quite complicated, the backend cannot rely on gtk+, > > because it would bring the dependency on the factory and the factory may > > not depend on the gtk+, it should be runnable without live desktop, only > > from a terminal. Correct me if I'm wrong. The idea of "another process > > taking care of the user interaction" is, apart of quite complicated, > > also not easy to do, what if you run the server without live desktop, or > > if you run on thin clients, or ... I'm afraid there can be many ways how > > to break this approach. Thus, what about adding a DBus signal on the > > backend for conflict resolution, something like: > >void resolve_sync_conflict ( > > guint sync_op_id, > > const gchar *server_object, > > const gchar *local_object); > > which backend will throw and the client side should response through > > something like this method: > >void sync_conflict_resolved ( > > guint sync_op_id, > > ESyncConflictResolution resolution); > > where ESyncConflictResolution will contain values like: > > Unknown > > ServerWins > > LocalWins > > ... (maybe more, Christian may advise better) > > Of course, the client part should implement this, which is basically > > undoable for all of them (and some even do not use gtk or any user > > interaction at all), thus I would add one parameter to the "synchronize" > > method, the ESyncConflictResolution value, which will pick the desired > > strategy. If it is "Unknown", then the backend can use the signal and > > wait for the method to resolve conflicts (better name from "Unknown" > > would be "Ask"). Of course, clients without user interface will not call > > the "synchronize" method, most likely. > > > > The resolve_sync_conflict() uses strings for objects, and based on the > > EClient type it's either ECalComponent or EVCard as string. > > You are right, it is too easy to forget that E-D-S better not depend > on UI. As for evolution-kolab, if there is no client connected, then > no synchronize() action would be triggered, hence no sync conflict would > occur. Only if there is a client actually requesting objects or a server > synchronization, then the backend would become active and actually *do* > something. Otherwise it would be sitting idle and not be trying to keep > up with server changes (object changed on server -- backend pulls -- > object is changed back on server -- backend pulls --- ... I think a lazy > approach would be the better one here). > > >
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 option
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] Return back folder remember for Open/Save dialog
On Mon, 2012-07-23 at 11:04 +0100, David Woodhouse wrote: > I strongly disagree that consistency with other Gtk+ applications is > more important than basic usability. The GtkFileChooser is just > stunningly broken — and by accepting its stupidity wholesale, that means > that Evolution has regressed in usability. > > I agree with Milan that we should switch back to how we were doing > things before. That effort would better be put into improving GTK+ itself for everyone, rather than just fixing up Evolution. Philip > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > https://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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Some minor Camel API breaks
On Mon, 2012-08-13 at 08:19 -0400, Matthew Barnes wrote: > * 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. 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? Then again, ATK uses the ‘_ref_’ convention, so there seems to be no consistent standard anyway. 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] 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] 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] 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] 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 > To: Milan Crha > Cc: evolution-hackers ; will.yu > > 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] Introspection enablement for libecal - huge changes needed?
On Thu, 2014-05-15 at 15:15 +0200, Milan Crha wrote: > On Thu, 2014-05-15 at 11:13 +0100, Philip Withnall wrote: > > 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. > > Hi, > we tried to "introspect" libical inside libecal, basically by boxing > libical types. The mos common error (warning) is about "Unresolved > type"-s. These involve icaltimezone and icalcomponent. Both types are > really defined as incomplete [1], but also out of the eds source. This > marks related functions as unintrospectable. > > Another issue is with enums. Also the naming is not what > gobject-introspection likes, there is no camel-case naming used in > libical. > > I suppose half of the problem would be to solved by generating gir files > directly in libical, but I'm afraid it'll not be enough, due to those > incomplete types (the enums might be fixed by this, I guess). So Fabiano asked about this in #gnome-hackers yesterday, and I think the conclusion was to do something similar to what's done in Cairo: add the G_DEFINE_BOXED_TYPE and glib-mkenums boilerplate somewhere (either directly in libical, or in a small libical-glib library which otherwise does *not* wrap the libical API). I think gobject-introspection will need fixing to support non-standard names for APIs and types. 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] Introspection enablement for libecal - huge changes needed?
On Fri, 2014-05-16 at 19:28 +0200, Milan Crha wrote: > The main problem is that the API returns pointers which are part of the > structure that you ask the value of it - like when you ask for a > subcomponent of an icalcomponent. If it exists, you get a child of the > parent component. This makes a disaster due to the unpredictable memory > management in python or javascript (introspection-using languages in > general?). The libecal uses this libical behaviour too. As an example, > if you ask for an alarm of an ECalComponent, then you receive a new > structure which holds a libical structure, which is part of the > ECalComponent (icalcomponent of it). Any changes done through this > structure are immediately propagated into the parent's ECalComponent, > aka there is no "save" involved. If you free ECalComponent before the > alarm structure, then the free of the alarm structure causes a crash. As > you cannot influence the memory-free time in python... and even if it > would be possible, then we cannot expect from the introspection > interface users (developers) to tweak their code in a way they are not > used to (like making some memory/variable management on their own). Ah, that makes a lot of sense. Shame. :( 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] [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
[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] 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
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] 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
