[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Aug 24 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates http://live.gnome.org/Evolution/CommunityMeet - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - June 29 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates Note: As many core developers are on leave during the 3rd and 4th week Wednesday's of this month. We are postponing the meeting to the last Wednesday of this month, June 29. - Chenthill. ___ 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] [EDS PATCHES] ecal item semantic (was: [Fwd: Re: e_cal_remove_object_with_mod() + empty rid: semantic?])
On Thu, 2011-06-02 at 13:41 +0200, Patrick Ohly wrote: Hello Chenthill! You are the calendar maintainer, right? Do you have some time to review these patches? On this occasion let me add some further explanation of the motivation for this patch series. Can you please attach these patches on to bugzilla ? I will put the comments there. I can do it myself, but there is no option to specify the author, so it would be better if you can do it.. - Chenthill. Traditionally, libecal has implemented parts of the semantic typically associated with a UI: for example, it implements ensure that a recurring event does not occur at this point in time, no matter what it takes to achieve that. I consider this a high-level API. The low-level API would be remove/add/modify this VEVENT. The libecal API *looks* like it supports that and according to our previous discussion is meant to (see the comments about e_cal_remove_object_with_mod()), but the actual implementation differs. This is a problem for sync operations, where that semantic is implemented elsewhere and the calendar storage has to mirror the operations done there (CalDAV/SyncML server in SyncEvolution; KCal in the MeeGo architecture). Therefore this patch series adds the missing operations. This is done so that the file backend can replace other local storages that EDS is being compared against. I understand that the vision of EDS goes beyond just being a local storage, but that's irrelevant in the context of such comparisons (unfortunately). email message attachment (Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?), Forwarded message - Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic? Forwarded Message From: Patrick Ohly patrick.o...@gmx.de To: Evolution Hackers evolution-hackers@gnome.org Subject: Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic? Date: Tue, 17 May 2011 10:58:12 +0200 Mailer: Evolution 2.30.4 On Mo, 2011-05-16 at 18:06 +0200, Patrick Ohly wrote: I'll do it as uid[\nrid] so that entries without an rid continue to look exactly like the current ones. Looks good. I ran my KCal-EDS test program which adds, modifies and removes events, including parent and child (= detached recurrence) in various orders. I am now seeing all ECalView signals that I expect and need. I also ran Evolution in parallel to the test and saw it react to all signals, but not quite as I would have liked. Evolution seems to interpret uid + empty rid as all recurrences removed, which IMHO is wrong. It should mean parent removed, because otherwise there is no way of expressing that change. For child removed, parent not updated (= no EXDATE added) I would expect Evolution to show the original, unmodified recurrence again. Instead it only removes the recurrence (as if EXDATE had been added). I consider this an Evolution bug which can and should be fixed separately. Please understand that it is currently lower priority for me, my main goal has to be to get EDS working as intended in EKCal-EDS, without Evolution. Please have a look at the attached patch series. They were tested with the gnome-2-32 branch. Except for the very last one, all apply to master. Does this look okay? May I submit to master (after fixing the last patch), gnome-3-0 and gnome-2-32? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - May 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates Check out http://live.gnome.org/Evolution/CommunityMeet for more details. - Chenthill. ___ 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] Gtk-ERROR **: GTK+ 3 symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
On Thu, 2011-02-03 at 13:33 -0500, Matthew Barnes wrote: On Thu, 2011-02-03 at 12:43 -0500, Reid Thompson wrote: Is there a way to determine where I'm mixing GTK 2 3? I'm not aware of a good way. In the past I've had to pick through pkgconfig files to figure out what's dragging it in, but it's slow and painful. You could also prolly check the Makefile to see what package to picking up the gtk2 libs.. - Chenthill. Evolution, Evolution-Data-Server and GtkHtml are all pure GTK3 now so it must be an external dependency dragging it in. It might be that we just need to bump a version requirement somewhere, or it might be deeper than that. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Dec 22 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ 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] Building against gtk3
On Tue, 2010-12-14 at 08:33 -0500, Matthew Barnes wrote: On Tue, 2010-12-14 at 04:47 -0700, Vibha Yadav wrote: Evolution is now compilable against gtk3. Please checkout the gtk3 branch for + gtkhtml + evolution-data-server + evolution Awesome! Nice work! +1 :) - Chenthill. Let's hope that's the last of the API breaks. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Nov 24 - 3:30 PM UTC
On Tue, 2010-11-16 at 08:29 +0530, chen wrote: Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates The meeting was post-poned last week since many core developers were on leave. The meeting will happen on Nov 23 during the same time mentioned. - Chenthill. - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Nov 17 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - oct 20 - 3:30 PM UTC
Hi, The meeting goes as follows, * Update on EWS plan * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ 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] Merging the collaboration providers in a single package
On Mon, 2010-10-18 at 09:21 -0600, Sankar P wrote: On 10/18/2010 at 07:01 PM, in message 1287408711.3126.11.ca...@localhost.localdomain, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2010-10-18 at 12:10 +0530, chen wrote: The other solution was to maintain all exchange providers in a single package, merging evolution-exchange, evolution-ews and evolution-mapi into a single package. Other collaboration providers like evolution-groupwise and evolution-kolab (yet to be upstreamed) will remain as separate packages. If we -have- to glob providers together I would prefer the alternate solution: merge all the Exchange providers into one git module, break GroupWise out from E-D-S into it's own git module, and leave the rest alone. This is not unlike the recent gnome-games debate on desktop-devel-list, except that we already have shared libraries for the common parts with fairly stable APIs (libebook, libecal, etc.). Jon's comments on the gnome-games issue reflect my own for this one: http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00049.html The control/ownership of the code can be made clear using provider-level maintainer-ship (like groupwise, exchange, kolab2 maintainers etc.) inside a single package. Of-course package is one, but with independent sub-modules and owners. Is there any other disadvantage or point of concern ? I prefer not to have every provider in its own module. If we make changes in the baseclass, it will be ignored and won't go into unmaintained providers. More providers translates to more work for packagers downstream and also during the release time for maintainers as well, with not much benefits. Just my 2 cents. I agree. I would not term as un-maintained providers. If they are really un-maintained, which means many bugs exist and people are not able to use it, it has to be pruned at some point. But certainly I see advantages to have the providers in a single package which would help us adapt to the API changes well, translations could be shared, packagers can look for updates for one package and maintainers would have less burden in releasing many packages. - Chenthill. Sankar ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Merging the collaboration providers in a single package
Hi, We had discussed about merging the collaborative providers such as evolution-exchange, evolution-mapi, groupwise, kolab and evolution-ews (on development) into a single package in previous community meeting. There are certain advantages and some concern areas in it, let me summarize them on what we discussed in the community meeting (http://projects.gnome.org/evolution/meeting-logs/2010-09-15.shtml), Advantages of having the providers in a single package: + All the API updates can be adapted to the providers and made sure all the providers compile. + Packagers can looks for updates from one package rather than evolution-groupwise, evolution-exchange, evolution-ews, evolution-kolab etc. Concern areas: + We may have to be pruning some backends if there are no bug fixes and if its not kept alive (for eg: google backend was replaced with caldav for the same reason) + The bugs from various packages have to be moved to a single package in bugzilla. Of-course some authors third-party external backends may not be interested or may not be possible due to some licencing issues. But we can at-least facilitate it if the authors and evolution maintainers are interested in maintaining it. The other solution was to maintain all exchange providers in a single package, merging evolution-exchange, evolution-ews and evolution-mapi into a single package. Other collaboration providers like evolution-groupwise and evolution-kolab (yet to be upstreamed) will remain as separate packages. My personal opinion is to club all the collaboration providers into a single package would be good. It would be good if we discuss the pro's and con's more deeper and involve packagers as well while moving on to a solution. Thanks, Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: IMAPX licensing
On Mon, 2010-09-13 at 17:19 +0200, Christian Hilberg wrote:
Hello again.
While working through the IMAPX sources, I noticed that there are three kinds
of licenses in the headers for the *.[hc] files of the IMAPX implementation:
* GPLv2
* LGPLv2
* {nil}
The COPYING file in the E-D-S toplevel directory states LGPLv2, this is what
we checked initially.
Are the IMAPX file headers going to be fixed in near future regarding
licensing information? And if so, which will be the license they're going to
be placed under? This will have a major impact on licensing considerations
for
our evolution-kolab plugin (which we planned to release under LGPLv2.1+).
Yes I had missed to notice the GPLv2 licences that existed. LGPLv2 is
the license which all the files in EDS should be using. Will update and
inform you.
Thanks, Chenthill.
Thanks in advance for any helpful information.
Best 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
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution branched for GNOME 2.32
Hi, The following modules have been branched for GNOME 2.32, gtkhtml, evolution-data-server, evolution and evolution-exchange. The branch is gnome-2-32. Hard code freeze starts from Sep 13 and ends on Sep 27. Please do not commit any patches to gnome-2-32 branch until hard-code freeze ends. Exceptions are allowed with the approval from release team. The patches which apply to the stable branch can be committed to gnome-2-32 branch after Sep 27th. The master is now free for commits and void of all freezes. The patches with accepted-commit-after-freeze state can be committed to master now. Thanks, Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel IMAPX RFC5464 compliance
On Wed, 2010-08-18 at 10:30 +0200, Christian Hilberg wrote: Hi everyone, On Thursday 05 August 2010 David Woodhouse wrote: On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote: Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? [...] I would strongly recommend that you do it in the development branch first, then we can backport it to gnome-2-30. I've been backporting most IMAPX changes from master to the 2.30 branch; I see no particular reason why we shouldn't backport METADATA support too, as long as you're careful not to add new user-visible strings that would need translation. Okay, let's say, we will patch upstream IMAPX to support RFC5464. The patch gets reviewed, and after being polished it will (hopefully :-) be accepted in upstream. How long do you think it would take you to backport such a patch to 2.30, assuming we heed to the aforementioned implementation recommendations? It should just take a day or two once its approved. You just need to keep in mind that its not possible to add string/UI changes in gnome-2-30 branch. I am assuming that string changes would not be need since you would just check for server capabilities and add the meta data.. - Chenthill. Best 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - July 18 - 3:30 PM UTC
Hi, This is first meeting after our GUADEC 2010! There would be some interesting updates during meeting. The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ 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] [Reminder] Evolution community meeting at #evolution-meet channel - Aug 18 - 3:30 PM UTC
On Mon, 2010-08-16 at 18:20 +0530, Srinivasa Ragavan wrote: On Mon, Aug 16, 2010 at 6:00 PM, chen pchenth...@novell.com wrote: Hi, This is first meeting after our GUADEC 2010! There would be some interesting updates during meeting. The meeting goes as follows, It probably should be Aug 18 :-) Thanks for correcting. /me tells to himself - either dont copy paste or make the template dynamic :) - Chenthill. -Srini. * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: Hi all, ...still continuing... Kolab makes use of RFC5464 - The IMAP METADATA Extension IMAP folder annotations to differentiate between the various folder types which are handled by Kolab. Remember, anything (Email and PIM data) is stored as Email messages with XML attachments in IMAP folders within the Kolab context. This means, we have IMAP folders for Email, Calendars, Contacts, TODOs, Tasks and the like. Now, when creating a Kolab account, all of these folder types are generated on the server. There is at least one folder for each type, which is the default folder initially. From within Evolution, *only* the IMAP folder which is annotated Email should be visible and all others should be hidden, as their respective contents will be managed by the backends, not Evolution. Otherwise, users will be able to meddle with PIM data folders, which might result in disastrous situations on the server side. Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? This cannot be done in a fool-proof way for IMAP as it does not provide information on the type of the folder. This can be done with an assumption that calendar folder will be named as 'calendar' or contact folders as 'contacts'. The other thought I get is, the contacts+calendar folder names can be collected as an option in account-setup and set as part of camel url (prolly through a kolab plugin, hiding it from the user. you can check how groupwise account set-up is implemented for an example) say hide_folders=list of folders with a separator. If the parameter is set, the folders can be hidden while fetching folder_info through camel_store_get_folder_info (in imapx backend), which gives the folder tree. We could add another flag in CamelStore to over-ride the above option to fetch all folders while fetching the folders from contacts(EBookBackend)/calendar(ECalBackend) backends. I can help you with making these changes in imapx backend/CamelStore and inform you the changes which you would need to make in your account-setup plugin. Sounds ok? - Chenthill. Many greetings, 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: hiding IMAP folders
On Tue, 2010-07-20 at 12:41 +0200, Milan Crha wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? Hi, you said you want to use imapx internally, is it right? And even if only the imap provider itself, then I would suggest to subclass it (your base imap provider) in your evolution-kolab package and manage this within CamelStore::get_folder_info, by calling parent class' get_folder_info and then recreate folder information based on your needs (once with email folders only, once with calendar folders only, and so on). Just noticed the reply. I dont think it requires sub-classing as it seems to be applying for other collaborative backends such as groupwise where we would need to hide some folders iirc it was tasks/contacts (sorry forgot the exact folders), but remember discussing with Akhil. - Chenthill. Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Couple new functions for ECal/EBook
On Tue, 2010-07-20 at 06:34 -0400, Matthew Barnes wrote: On Tue, 2010-07-20 at 11:21 +0530, chen wrote: Is it required ? Having it in ECalBackendStore simplifies the backend code to form the path based on the type (calendar,tasks,memos) at a single place rather than every backend doing it.. Forming the path at a single place instead of all the backends doing it is definitely the goal. My thought was just that ECalBackend can do it as easily as ECalBackendStore, since ECalBackendStore does nothing else with the URI + type it's given and the path still has to be shared with ECalBackendCache somehow. Moving it to ECalBackend seemed cleaner to me, but I can try to keep things as is if you'd prefer to avoid the API break. I am ok with having it in ECalBackend. Btw we could deprecate ECalBackendCache and update just ECalBackendStore. I thought of that, but evolution-mapi still uses ECalBackendCache pretty heavily. Should we give Bharath and Milan some time to migrate off it first? I hope they are doing it. Had a chat with Bharath a week back iirc as I realized just then that mapi was not migrated. It should take not more than half a day to migrate at the maximum. It should be more or less s/cache/store work :) - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Fwd: Re: Couple new functions for ECal/EBook]
---BeginMessage--- Migration has been done and I'll submit the patch soon. Regards Punit On Tue, 2010-07-20 at 16:56 +0530, chen wrote: On Tue, 2010-07-20 at 06:34 -0400, Matthew Barnes wrote: On Tue, 2010-07-20 at 11:21 +0530, chen wrote: Is it required ? Having it in ECalBackendStore simplifies the backend code to form the path based on the type (calendar,tasks,memos) at a single place rather than every backend doing it.. Forming the path at a single place instead of all the backends doing it is definitely the goal. My thought was just that ECalBackend can do it as easily as ECalBackendStore, since ECalBackendStore does nothing else with the URI + type it's given and the path still has to be shared with ECalBackendCache somehow. Moving it to ECalBackend seemed cleaner to me, but I can try to keep things as is if you'd prefer to avoid the API break. I am ok with having it in ECalBackend. Btw we could deprecate ECalBackendCache and update just ECalBackendStore. I thought of that, but evolution-mapi still uses ECalBackendCache pretty heavily. Should we give Bharath and Milan some time to migrate off it first? I hope they are doing it. Had a chat with Bharath a week back iirc as I realized just then that mapi was not migrated. It should take not more than half a day to migrate at the maximum. It should be more or less s/cache/store work :) - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ---End Message--- ___ 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] Couple new functions for ECal/EBook
On Mon, 2010-07-19 at 17:27 -0400, Matthew Barnes wrote: On Mon, 2010-07-19 at 09:10 +0200, Milan Crha wrote: that's a part which should be changed. The ideal way, as I understand it, is to have an ECalBackend function to retrieve a path for attachments, and ECal should ask backend for it, instead of duplicating the code (it sort of blocks extendibility of ECalBackend, because the client side depends on the code in evolution-data-server itself, which is kinda wrong). It will be good to fix this and move functions to libedata-book/cal, where they, as you said, belong anyway. I took Milan's advice and attempted to do this The Right Way... I think. Here's what's changed: Instead of adding standalone functions, I added a cache-dir property along with the usual get/set functions to EBookBackend and ECalBackend. The property is read/write, but the default value should rarely be overwritten (currently only the file backends override it). const gchar * e_book_backend_get_cache_dir (EBookBackend *backend); void e_book_backend_set_cache_dir (EBookBackend *backend, const gchar *cache_dir); const gchar * e_cal_backend_get_cache_dir (ECalBackend *backend); void e_cal_backend_set_cache_dir (ECalBackend *backend, const gchar *cache_dir); Also I slightly broke the API of ECalBackendCache and ECalBackendStore to take a cache file name or cache directory name (respectively) instead of a URI and ECalSourceType, since the URI and ECalSourceType are only used to build a cache file name or cache directory name. Backends using these classes can easily construct a suitable cache file or directory name from e_cal_backend_get_cache_dir(). get_cache_dir can simply return e_cal_backend_store_get_path. ECalBackendCache * e_cal_backend_cache_new (const gchar *filename); ECalBackendFileStore * e_cal_backend_file_store_new (const gchar *path); Is it required ? Having it in ECalBackendStore simplifies the backend code to form the path based on the type (calendar,tasks,memos) at a single place rather than every backend doing it.. So now the name of a backend's base cache directory is centralized in its base class. That takes care of the server side. For the client side I added a simple ECal D-Bus method getCacheDir(), which does what it says. ECal still caches the directory internally, so the method will only be called once per ECal instance. I did not add a similar D-Bus method to EBook because there's currently no need for it, but we could easily add it later if desired. How does this sound? Any objections to the minor API break in the backend libraries? Btw we could deprecate ECalBackendCache and update just ECalBackendStore. - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - July 14 - 3:30 PM UTC
On Tue, 2010-07-13 at 11:34 +0530, Srinivasa Ragavan wrote: On Tue, Jul 13, 2010 at 11:07 AM, chen pchenth...@novell.com wrote: Hi all, Our this month's community meeting happens on July 14th. This would be the community meeting before GUADEC 2011!! Isn't this supposed to be GUADEC 2010? ;-) it is 2010, good observation :) - Chenthill. -Srini. Post any queries to the list today if you want them to be answered in the community meeting. Gives some thinking time for all the people for a fruitful discussion. I will add a link to the wiki for the community meetings to collect the questions for the forth coming meetings. Query from me for this meeting to discuss: + Having evolution-collab-backends to hold all collab backends ? - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Tue, 2010-07-13 at 15:36 +0200, Christian Hilberg wrote: Hi again, no ideas? Anything? I will summarize some of the DataStructures here which you will be using in the backend, ECalComponent - This holds the calendar event's data in Ical format. It wraps Icalcomponent, but has not completely wrapped the same. So both are used at places. ECalComponent is better to use as its a Gobject. ECalBackendSync - Abstract class from which you would need to subclass kolab backend. (http://live.gnome.org/Evolution/CalendarStore) ECalBackend - Use api's from this class to notify the clients on event changes (_remove, _added, _modified). ECalBackendStore - Abstract class for the calendar cache. ECalBackendFileStore - file is derived class of the above class and used for storing calendar contents. ECalBackendFactory - Abstract class for the factory which your backend needs to subclass. e-cal-utils.h - should have some utility functions. http://www.go-evolution.org/EDS_Architecture - I find that its not there in lgo, will need to be migrated. Having this as pointers and looking through existing backend implementation would give you a better idea. - Chenthill. Best 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Wed, 2010-07-14 at 13:23 +0100, Ross Burton wrote: On Wed, 2010-07-14 at 17:37 +0530, chen wrote: ECalBackendSync - Abstract class from which you would need to subclass kolab backend. (http://live.gnome.org/Evolution/CalendarStore) Though only subclass this if you can't handle the async nature of the ECalBackend API yourself. Whether you subclass ECalBackend or ECalBackenSync is a choice made by how the backend will be implemented. Is this used by any backends or will be used ? I was just having this question while reading through the go-evolution.org link. ECalBackendSYnc adds the notification to the clients for the sync calls made by the clients through libecal, which anyways cant be ignored isn it ? So usage of ECalBackend functions for sync calls such as, e_cal_backend_create_object, get_object, get_object_list etc. just adds extra work of notifying the clients using e_data_cal_notify*. If the answer is, they are not used, better to mark them as deprecated and cleanup this area. ECalBackend can then just be used for Async apis like, e_cal_backend_notify_object_(added, modified, removed) and future free/busy async apis etc. - Chenthill. 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
Re: [Evolution-hackers] imapx: Avoid running FETCH_NEW_MESSAGES and REFRESH_INFO jobs simultaneously
On Sun, 2010-07-11 at 15:35 +0100, David Woodhouse wrote: On Sun, 2010-07-11 at 15:11 +0100, David Woodhouse wrote: From 1d1b146e58f918f67ccff93c4fb5388429bf12e7 Mon Sep 17 00:00:00 2001 From: David Woodhouse david.woodho...@intel.com Date: Sun, 11 Jul 2010 15:11:17 +0100 Subject: [PATCH] imapx: Avoid running FETCH_NEW_MESSAGES and REFRESH_INFO jobs simultaneously There are various places where we interpret FETCH results and use imapx_match_active_job to find the current job, which will behave badly if there are two jobs which could potentially be responsible for the FETCH. In particular, this was causing a problem when we triggered a fetch of new messages from select_done(), and that command was submitted at the same time as a refresh_info command to fetch all flags. The server (Dovecot) was returning all the untagged FETCH results before either completion line, and all the flags were getting assigned to the fetch_new_messages job, causing a bunch of 'g_array_append_vals: assertion `array' failed' warnings, and all messages to disappear because the refresh_info job didn't see them. I looked at fixing this by making the FETCH handling code work out which job it should be looking at.. but that's hard because of the ways in which a fetch_new_messages job might just be fetching flags, and a refresh_info job might fetch new messages. The real fix, I think, is to stop the FETCH handling code from caring about the jobs at all. The untagged messages tell us about the state of the mailbox, and we should just deal with that information as it comes in, without worrying about _why_ the server is sending it. For refresh_info to notice when messages are deleted, we could set a 'possibly expunged' flag in the message in our local store, then the FETCH handler could clear that flag whenever it gets flags for a message. The refresh_info logic would then be: - Set this flag on all messages - Issue UID FETCH 1:* (UID FLAGS) - Delete all messages without this flag set. Seems fine, this is a better approach. I don't see a problem as only one refresh_info job can happen at a time. The idea would be to kill off _all_ use of job-u.refresh_info.infos and similar fields. Where we've fetched message flags before the headers, we could keep a list of those in the folder info, not the job. And that way, _wherever_ those new flags come from (SELECT, IDLE, NOOP, FETCH, etc.) they'll get handled consistently. I was just thinking whether we would need the logic to fetch new messages from refresh_info job at-all while scanning for changes. We fetch new messages always before scanning for changes, so ideally scan_changes should only sync the flags. At this point, fetching new messages from scan_changes would be used very rarely if there was any message deleted wrongly in cache (due to wrong unsolicited response from server or client bug) as a fall-back mechanism to recover those messages. So how about re-fetching those flags in those cases (which anyway happens rarely). So this simplifies the logic to not store uid, flags without headers for those messages in the folder info. All use of imapx_match_active_job() without a uid parameter would then be considered a bug. Fine. - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: local cache for offline-work
On Fri, 2010-07-09 at 19:20 +0200, Christian Hilberg wrote: Hi Chen, thank you very much for taking time to clarify things! Much appreciated. On Friday 09 July 2010 at 18:43:32 chen wrote: On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote: * Does there exist any infrastructure in E-D-S which will help us creating a local email cache via IMAP? Yes its available. CamelFolderSummary stores all the basic contents of an email which needs to be displayed in the MessageList view (label, subject, dates, fromto headers etc.). CamelDataCache stores the contents of the email (entire mime message) into the cache. The imapx provider would use them to store the mail data into cache. Okay, this helps. I think I saw these parts of Camel before, but I was not sure whether the facility provided would be sufficient for our needs. Seems we have what we need here. * Orelse, is there a sensible way to re-use existing caching functionality inside our backend which comes from Evolution, since Email handling resides there, presently? Without weaving knots between Evo and E-D-S which will be prone to failure and unclean, I mean? Current imapx provider implementation is in such a way that, once you access a message using camel_folder_get_message, the message would be completely downloaded into the cache and would be available for offline usage. camel_folder_refresh_info would fetch the summary contents and optionally fetch the message contents also if the folder is marked for offline usage (when the camel url property, 'sync_offline' is set). Again, this is valuable information. If I read this correctly, the IMAPX implementation would handle all caching so we would be left with only the actual synchronization problem. BTW, is there a way to intercept Camel's synchronization with the IMAP server after reconnecting (i.e., after leaving offline mode)? This question is because the PIM emails hold semantics to which Camel will be agnostic (since it thinks it only handles emails), and it could be problematic to cope with PIM sync conflicts if Camel will just sync the emails right away without a possiblitiy for us to hook-in an awful lot of extra sync logic. You could connect to the signal 'changed' on the camel folder. This would give you information on new/deleted/changed messages once the folder is synchronized with the imap server. http://live.gnome.org/Evolution/Camel.Folder - checkout CamelFolderChangeInfo . Btw the contents of the emails (mime message with Xml calendar/contacts data) would be cached in camel (usually under ~/.evolution/mail/imapx/account/folders/folder/ ) while mails are fetched (through camel_folder_get_message). You could delete those contents after converting them to ICal or VCard and storing the data in the respective backends, by using camel_data_cache apis from calendar/address-book backends to remove duplicate data. - Chenthill. And i guess you would be re-using the existing imapx backend from evolution ? By all means! :-) Once you convert the xml data to Ical or VCard, you can make them available for offline usage based on ESource property, 'offline-sync'. Well well, this all sounds promising. [...] Once I'M really clear that we have to do these things fully on our own and we cannot re-use existing infrastructure, I will instantly stop harassing you with this issue and start working. :-) I just want to avoid reinventing the wheel. Oh np :) You can shoot your queries anytime.. Btw to be more clear no one has tried using camel apis from calendar+address-book backends. I think Matthew already mentioned this. But we will give it a try - not many options for us to choose from. :-) It might be a good idea to use separate instances of Camel providers for contacts and calendar data. We'll see. Thanks for all the fish :-) 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: Lifting the veil
On Fri, 2010-07-09 at 14:22 -0400, Matthew Barnes wrote: On Fri, 2010-07-09 at 10:29 -0600, Sankar P wrote: (oh that out-of-tree Scalix backend is still using flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types) Is evolution-scalix even alive? It hasn't seen a release in over two years. Same goes for evolution-jescs. How about having all the collab-backends into a single package ? evolution-collab-backends, which can hold exchange, groupwise, mapi, kolab, (google?) etc. ? Any cons that you see ? At-least we wanted to keep the backends such as Imap, pop, caldav, etc. which were independent component providers inside eds itself. - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: local cache for offline-work
On Thu, 2010-07-08 at 15:50 +0200, Christian Hilberg wrote: Hi all, in evolution-kolab, we need to provide full offline capabilities for working with Kolab 2 groupware data in offline mode. Evo 2.30 has an offline mode which works for IMAP email. If I understood correctly, email handling resides within Evolution presently [1], not E-D-S. For our plugin, though, we need to place email stuff in the backend (for handling contact data and calendar data, as these are stored in XML attachments to emails within Kolab 2 context). This means we will need to sync emails (with proper conflict resolution) when re-connecting to the Kolab server which hold calendar data and contact data. What's more, we have a multimaster-situation here. As Matthew already pointed out in [2], this is sort of new terrain we're stepping on. In order to get an idea about how much work it will be to implement this feature, I'd like to know whether there are ideas already concerning caching calendar data and address data this way. Alas, I have not found time yet to dig into existing backends to check whether they do caching already or whether there is any infrastructure provided with Evo/EDS 2.30 which we could use for that matter. We'll be happy to receive any pointers into existing plugins where something like this is already done or to discussions about the issue. Let me try to summarize some pointers for calendar and you could do the same for address-book as well, + Create New ECalBackend for Kolab + Use the camel apis to fetch the calendar folder + Using the CamelFolder, get its contents. You would mime data and you can use the Camel libraries again to parse these contents. + Convert the Xml calendar data into Ics format and store it into the backend So this helps for displaying the contents. Now with creating meetings/appointments. iirc you would need to send them via smtp ? + use the camel_transport apis (look through e_cal_backend_save/send api's) There are many backend implementations already available file, exchange, groupwise etc. and you can refer them.. I would recommend looking through groupwise/exchange and shoot your questions if any.. Since no one has yet tried using camel apis, we do not know if there are any issues while you might face. But we should be able to help you while you progress.. The same holds good for address-book also. Thanks, Chenthill. Thanks in advance, Christian [1] http://mail.gnome.org/archives/evolution-hackers/2010-June/msg00018.html [2] http://mail.gnome.org/archives/evolution-hackers/2010-June/msg00022.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: Lifting the veil
On Thu, 2010-07-08 at 13:01 -0400, Matthew Barnes wrote: On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote: If Evolution staff will be willing to host our project sources within Evo git repo, we'll happily transfer our stuff there as soon as we have a first preview ready. Perhaps something to dicuss on #evolution (irc.gimp.net) - but it'd be great to have you working in the same git repo IMHO [ not that it's my decision of course - I defer to Matthew/Chen etc. ;-] Certainly aim for hosting your project on git.gnome.org, but I'd still prefer it be split into a separate evolution-kolab repository similar to evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm told). It just keeps things more modular and it keeps us honest: our public APIs -have- to be complete since external projects don't have access to private in-tree APIs. The separation is not meant to be a barrier between you and us, just an implementation detail. While thinking about this, I just got a thought of why not a, evolution-collab-backends package which can hold all the eds collborative backends (that provides mail+calendar+address-book) such as mapi, exchange, groupwise with sufficient configuration options to choose what to compile ? This would help in making the api changes to all backends and keep external backends connected. I support maintaining the backend code in a separate package though. Its easier to provide updates to the backends if its not part of eds at-least with some distros (at-least with suse as I use it). - Chenthill. The process for obtaining a gnome.org account is here: http://live.gnome.org/NewAccounts Each of your developers should apply for their own account, but I would suggest waiting to do this until after you have a working public beta, as you'll have more credibility to the gnome.org admins then (which is not us!). Once you have your gnome.org accounts, you can clone your git repository on git.gnome.org by following the procedure here: http://live.gnome.org/Git/NewRepository Hope this helps. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-kolab: local cache for offline-work
On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote: On Friday 09 July 2010 at 18:01:53 chen wrote: [...] Let me try to summarize some pointers for calendar and you could do the same for address-book as well, + Create New ECalBackend for Kolab + Use the camel apis to fetch the calendar folder + Using the CamelFolder, get its contents. You would mime data and you can use the Camel libraries again to parse these contents. + Convert the Xml calendar data into Ics format and store it into the backend Yeah, this much is clear. There will be a fully-fledged two-way lossless conversion between EDS data types and Kolab2 data types, and the conversion will most probably be done on-the-fly (if we run into performance issues here, we might change plans... :). So this helps for displaying the contents. Now with creating meetings/appointments. iirc you would need to send them via smtp ? + use the camel_transport apis (look through e_cal_backend_save/send api's) Also no worries so far. Let me be a little more specific (I should have been right away, but my mails tend to become lengthy...): * We need to create a local cache for emails which is handled by the plugin backend(s). * Does there exist any infrastructure in E-D-S which will help us creating a local email cache via IMAP? Yes its available. CamelFolderSummary stores all the basic contents of an email which needs to be displayed in the MessageList view (label, subject, dates, fromto headers etc.). CamelDataCache stores the contents of the email (entire mime message) into the cache. The imapx provider would use them to store the mail data into cache. * Orelse, is there a sensible way to re-use existing caching functionality inside our backend which comes from Evolution, since Email handling resides there, presently? Without weaving knots between Evo and E-D-S which will be prone to failure and unclean, I mean? Current imapx provider implementation is in such a way that, once you access a message using camel_folder_get_message, the message would be completely downloaded into the cache and would be available for offline usage. camel_folder_refresh_info would fetch the summary contents and optionally fetch the message contents also if the folder is marked for offline usage (when the camel url property, 'sync_offline' is set). And i guess you would be re-using the existing imapx backend from evolution ? Once you convert the xml data to Ical or VCard, you can make them available for offline usage based on ESource property, 'offline-sync'. There are many backend implementations already available file, exchange, groupwise etc. and you can refer them.. I would recommend looking through groupwise/exchange and shoot your questions if any.. I'm in the process of having a closer look at them... Since no one has yet tried using camel apis, we do not know if there are any issues while you might face. But we should be able to help you while you progress.. Okay, thanks. Once I'M really clear that we have to do these things fully on our own and we cannot re-use existing infrastructure, I will instantly stop harassing you with this issue and start working. :-) I just want to avoid reinventing the wheel. Oh np :) You can shoot your queries anytime.. Btw to be more clear no one has tried using camel apis from calendar+address-book backends. Thanks, Chenthill. Best 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
Re: [Evolution-hackers] default calendar reminders
On Mon, 2010-07-05 at 13:33 +0200, Patrick Ohly wrote: Hello! How is Evolution's Show a reminder some time before every appointment feature meant to be implemented? Is that something that has to be checked each time an appointment is created (in which case SyncEvolution would have to be updated) or is this a feature that applies to all existing appointments, including those without alarm set? This is a wrongly phrased string and needs to be corrected. Maybe like, Set default reminders for the new appointments created/received sometime before the appointment time. So it was meant to be this way and has been implemented in the backend's the same way. I would recommend changing the string. I find the first interpretation useful as it provides a default and allows one to override it if required. I find the second interpretation much more useful, and not just because it would save me some trouble in SyncEvolution ;-) For example, it allows users to turn this on and off without having to edit all existing appointments. The user guide also makes is sound like it applies to all events, not just those which will be created in the future: http://docs.sun.com/app/docs/doc/817-7308/6mmkt57s1?a=view Coming to the second interpretation. This is different than first and must be implemented in alarm-daemon and with the above string. Another different enhancement IMHO. But looking at the code, I only find references to calendar-config.h's calendar_config_get_use_default_reminder() in a few places, but not in evolution/calendar/gui/alarm-notify where I would expect it to be used if it was meant to apply to all appointments. Think the above explanation answers it. - Chenthill. ___ 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] Heads-up: EBookBackend/EBook ECalBackend/ECal ongoing API changes
On Thu, 2010-07-01 at 13:41 +0200, Christian Hilberg wrote: On Thursday 01 Juli 2010 at 08:58:32 Milan Crha wrote: Hi all, I'm working on a way to be able to report detailed errors from addressbook/calendar backends to UI, so users will be able to see something more sensible than just Other error message in Evolution. This is bug report for this [1], which I'm working on right now. [...] Are there any plans to backport this to Evo/EDS 2.30.x (I suppose not)? All freezes (api/abi/string/feature) etc. hold good with the stable branch (gnome-2-30 or 2.30.x). So we will not back-port. - Chenthill. Greetings, 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 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [evolution-kolab] IMAPX and sync- vs. async-Backends
On Tue, 2010-06-29 at 16:14 +0200, Christian Hilberg wrote: Hi there, reading about the new IMAPX implementation used by Evo =2.30, I found it stated that Maybe if imapx had come up before, many backends such as groupwise, mapi etc. would have followed this design rather than a sync one. -- Chenthill in [1] Does this mean that the Camel IMAPX code is ready to support a backend like ours (for Kolab2) to be implemented as an async one rather than a sync one (which is the case for the MAPI-, Exchange- and SCALIX-Backends (and maybe others, too))? The internal implementation of IMAPX provider is async, the requests would be pipelined and run based on priority. Which means that one would be able to fetch multiple messages parallely unlike other providers where its sequential. Though one would have to still use the sync api's which camel provides. Adding new camel async api's is a task for future. - Chenthill. Best regards, Christian [1] http://chenthill.wordpress.com/2010/01/11/evolution-with-improved-imap-support-imapx/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] IMAP vs. IMAPX in Evo 2.30--recommendations?
On Tue, 2010-06-29 at 15:22 -0400, Paul Smith wrote: Hi all. I'm wondering if anyone can provide a summary/recommendation for IMAP vs. IMAP+ (IMAPX) in Evo 2.30 (I'm actually building the very latest gnome-2.30 branch from git)? I use a dovecot IMAP server which I don't think supports any of the advanced IMAP features (?), but I see that the IMAPX implementation in Evo is constantly being fixed/updated (by David Woodhouse lately) while the IMAP backend seems stagnant (or stable?). Should I switch my accounts to use IMAPX instead of IMAP? yes very much recommended. What about (does anyone know) connecting to Exchange servers using Exchange's IMAP? Should I be using IMAPX there? You can use imapx for both exchange and dovecot. As you have already observed there is good progress here. IMAP+ would be made the default on 3.0. We had set the default to imap in gnome-2-30 since that was first release of imapx. Evolution 3.0 should have imapx as the default. We might also think of dropping imap provider in future once we make sure all user needs are satisfied with imapx. Currently imapx is in feature parity with imap provider. imap extensions such as condstore would be implemented in imapx, there are already some fixes getting in on those lines.. Thanks, Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution 2.30.2 stable release - June 21st
Hi all, Evolution 2.30.2 stable release is scheduled to be released next week June 21st. Please commit all the important patches to the stable branch from upstream and downstream. Keep in mind that all freezes valid in stable branch gnome-2-30. Thanks, Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - June 16 - 3:30 PM UTC
Hi all, The meeting format goes as follows, * project updates * Discussions on specific bugs, decisions to be made etc. * status updates from everyone Please join the community meeting to share the interesting evolution stuffs your working on and discuss specific issues/doubts while all the active developers from different timezones would be available. Community meetings happen every month on third Wednesday's 3:30 PM UTC at #evolution-meet channel. Thanks, Chenthill. ___ 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] Base URI for On This Computer
On Wed, 2010-06-09 at 08:56 -0400, Matthew Barnes wrote: On Wed, 2010-06-09 at 08:41 -0400, Matthew Barnes wrote: So a local source group with a base URI of: file:///home/mbarnes/.evolution/calendar/local will become: file:///home/mbarnes/.local/share/evolution/calendar Let me rephrase this to try and better clarify: A local ESource with a URI of: file:///home/mbarnes/.evolution/calendar/local/unique-id will have to be changed as follows when we move to XDG base directories: file:///home/mbarnes/.local/share/evolution/calendar/unique-id but since they have to change anyway, I propose just naming it: local://unique-id to avoid the account migration problems I described previously. Yup makes sense. It is worth to list all the apps which uses eds for address-book and calendar and notify the changes to them or directly make changes there. I guess you might have this already in your to-do list :) Thanks, Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evo and Kolab2 - a fresh attempt
On Wed, 2010-05-26 at 11:18 +0100, Michael Meeks wrote: Hi Christian, On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: This sounds pretty cool and would be a welcome addition to the Evolution suite. Agreed. 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. Hopefully, it will be possible for us to do it that way. We have just begun our evaluation process, so lets see. Using the GLib'ified Evo code right from the start would be wise. Anyway, we'll have to check whether we can afford using Evo 2.30 / 2.31 as a code basis for our project... .. Phew, that's quite some time down the road. Our project is scheduled to show usable results (i.e. installable packages which work as expected) within this year. Sure - the question is: what is your distro target, and timeframe to ship ? are you going for RHEL / SLED / Ubuntu LTS ? or more community focused distros ? AFAICS the latest enterprise desktops current in late spring will have the underlying O/S deps necessary (GNOME 2.28) to build run the code as of now. Matthew / Chen - we have a general policy of not requiring the latest greatest platform until the next cycle right ? ;-) AFAICS gtk+ minimum version has been bumped and we had some reasons for that which could not recollect atm. Matt should be able to provide more information there.. We had been thinking of an option of using the latest stable evolution in enterprise releases once 3.0 is released, by installing the selected platform libraries which evolution requires in a different prefix so that other apps not affected by them. As such, it is entirely possible that if you want to ship and support a product you will need to compile your own evolution, and e-d-s to ship them [ hopefully the e-d-s calendar / contacts pieces that are used more widely in the OS will still stay ABI stable ;-) ]. There will be no breakages there, though there might be some apis added.. - Chenthill. That means we might have to use a current stable version of Evo for now. OTOH, it is also no fun to raise a project which is obsolete-by-design. We'll have to meditate on that. It'd be better really to develop vs. master - from a support, testing, future-proofing, and ease-of-use perspective. Presumably it is possible to get you commit access to the repository so you can develop in the repository [ when some code has been reviewed ] - it sucks to be stuck out on a limb somewhere. Anyhow - exciting to see this get underway; hopefully it can also be used as part of the Windows build - as a neat extra :-) ATB, Michael. ___ 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] Build failure in evolution 2.30.0 (was Re: Patch for Evo 2.30 - size of mail sidebar)
On Tue, 2010-03-30 at 10:18 -0400, Matthew Barnes wrote: On Tue, 2010-03-30 at 15:35 +0200, Vincent Untz wrote: Le mardi 30 mars 2010, à 09:18 -0400, Matthew Barnes a écrit : Even better, can we get a macro added to gnome-common that implements this deprecation flag policy, and perhaps even set a GNOME Goal for it? Sure, it'd be nice to have that. Please attach the patch in bugzilla, though: it will help get this integrated. FWIW, I'm not a maintainer of gnome-common, but I would prefer to have a configure flag for this too. Done. https://bugzilla.gnome.org/show_bug.cgi?id=614360 Released the updated tarballs for 2.30.0.1 - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution documentation
On Sun, 2010-01-31 at 17:47 -0500, Shreyas Phadnis wrote: hello all, I just got the latest evolution (from git master) up and running on my machine. I am testing few things specifically with IMAPX performance... is there any documentation on camel and its threading arch... and on IMAPX? http://live.gnome.org/Evolution/Developer/EDS or http://live.gnome.org/Evolution/Developer/ThreadingEmailCamel seems to be empty ...and i am not sure which documentation on go-evolution.org and projects.gnome.org/evolution/ is up-to-date There is no documentation for imapx yet. You can refer to the documentation for camel in www.go-evolution.org it is up to date as of now. Also feel free to clarify your doubts on irc #evolution channel. In the source tree I found this: http://git.gnome.org/cgit/evolution/tree/mail/README.async but it screams to be out-dated. I`d appreciate any pointers that would help me get started on evolution hacking... Would you be interested in putting some documentation for imapx while u learn the arch. where I could provide some help ? :) - Chenthill. Thanks, Shreyas (acewin on IRC) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Preconfiguring Evolution with gconftool-2
Hi Daniele, On Tue, 2009-12-22 at 21:38 +0100, Daniele Visaggio wrote: Hi guys, I'm trying to realize a script to preconfigure Evolution for my enteprise environment. Now I need to know what information do I have to give to Evolution in order to have a working configuration. The goal is to open Evolution for the first time WITHOUT the setup assistant. So, I ran this command to preconfigure a test gmail account in a fresh installed system: ## # gconftool-2 --set /apps/evolution/mail/accounts --type=list --list-type=string [?xml version=1.0? account name=daniele.visag...@gmail.com uid=1261512006.2036...@daniele-laptop enabled=trueidentitynameDaniele Visaggio/nameaddr-specdaniele.visag...@gmail.com/addr-specsigna ture uid=//identitysource save-passwd=true keep-on-server=false auto-check=true auto-check-timeout=10urlpop://daniele.visag...@pop.gmail.com/;comma nd=ssh%20-C%20-l%20%25u%20%25h%20exec%20/usr/sbin/imapd;use_ssl=always /url/sourcetransport save-passwd=trueurlsmtp://daniele.visaggio;auth=pl...@smtp.gmail.co m/;use_ssl=always/url/transportdrafts-foldermbox:/home/daniele/. evolution/mail/local#Drafts/drafts-foldersent-foldermbox:/home/dan iele/.evolution/mail/local#Sent/sent-folderauto-cc always=falserecipients/recipients/auto-ccauto-bcc always=falserecipients/recipients/auto-bccreceipt-policy policy=never/pgp encrypt-to-self=false always-trust=false always-sign=false no-imip-sign=false/smime sign-default=false encrypt-default=false encrypt-to-self=false//account ] ## # The command worked and, in fact, I red these data into the ~/.gconf/apps/evolution/mail/%gconf.xml file, but when I open evolution for the first time the data are automatically resetted and the setup assistant appears. The problem is, the values assigned are missing quotes, eg: enable=true should be enabled=true. Eg of a corrected string, gconftool-2 --set /apps/evolution/mail/accounts --type=list --list-type=string [?xml version=\1.0\?account name= \ak...@ocean.com\ uid=\1240202518.2907...@linux-adcj\ enabled= \falseidentitynameakhil/nameaddr-specak...@ocean.com/addr-specsignature uid=\\//identitysource save-passwd=\false\ keep-on-server=\false\ auto-check=\true\ auto-check-timeout=\10\urlimap://ak...@164.99.99.195/;imap_custom_headers;command=ssh%20-C%20-l%20%25u%20%25h%20exec%20/usr/sbin/imapd;use_ssl=never;soap_port=7191/url/sourcetransport save-passwd=\false\urlsmtp://ak...@164.99.99.195/;imap_custom_headers;command=ssh%20-C%20-l%20%25u%20%25h%20exec%20/usr/sbin/imapd;use_ssl=never;soap_port=7191/url/transportdrafts-foldermbox:/home/chen/.evolution/mail/local#Drafts/drafts-foldersent-foldermbox:/home/chen/.evolution/mail/local#Sent/sent-folderauto-cc always=\false\recipients/recipients/auto-ccauto-bcc always=\false\recipients/recipients/auto-bccreceipt-policy policy=\never\/pgp encrypt-to-self=\false\ always-trust=\false\ always-sign=\false\ no-imip-sign=\false\/smime sign-default=\false\ encrypt-default=\false\ encrypt-to-self=\false\//account] So, my question: 1) how can I force Evolution to mantain the data I put in with gconftool-2? 2) Is the configuration of the /apps/evolution/mail/accounts gconf key sufficient for Evolution to work (obviously limited to the evolution mail component)? Once you set the gconf string using gconf-tool. Kill gconf or use gconftool-2 --shutdown - for the values for to be synced. Try starting evolution from the terminal to see if there are any parsing errors. If there arent any, the account setup dialog wont popup. - Chenthill. Thank you in advance, Daniele Visaggio ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
On Wed, 2009-12-16 at 16:54 +0530, Srinivasa Ragavan wrote: On Wed, Dec 16, 2009 at 4:46 PM, Patrick Ohly patrick.o...@gmx.de wrote: On Wed, 2009-12-16 at 09:19 +0530, Chenthill wrote: On Tue, 2009-12-15 at 15:09 -0500, Reid Thompson wrote: On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote: * Not able to create subfolders under INBOX - https://bugzilla.gnome.org/show_bug.cgi?id=536240 . I hadn't noticed the above, so I guess it's a non-issue for me What is the second issue? Sorry missed to mention it here, with maildir we would need to rename files for unread/read flag changes which can be avoided in the later approach. So you expect renaming a file to be slower than rewriting the whole file content? Somehow my gut feeling says that it will be the other way around. But I don't have hard data, of course. I fell it will be slower compared to the other approach. You dont rewrite the file entirely at all in normal usage. May be when you expunge folder or export it, the summary data could be updated with the mail's mbox. But its debatable at some level, I would say. I don't think the rename triggers rewrite of a file. It isn a costly operation. But just wonder why we need to do that at all ? Could it be costly in distributed environments ? (not sure how significant this case would be for us) I also come across another issue, even if we start using maildir format, we cannot assume that multiple applications would access the data especially since local folders belong to evolution and would be used frequently. (see https://bugzilla.gnome.org/show_bug.cgi?id=592310 ) I definitely won't switch away from maildir as my format of choice because it integrates nicely with offlineimap. Sure, I think users should have that freedom. Camel's local folder implementation has that built in. This new approach should be the default for new users, and as option for users to migrate to it for existing users. If users willingly stay with maildir or 1mbox-per-folder that should also be there. Looking at the information gathered, am favoring Approach #2 - mboxfile-per-mail. I would be starting the work this week if I don't see any reasons to change the approach. Just want to put in the best possible solution :) - Chenthill. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] HEAD won't build - sed: -e expression #1, char 44: unknown option to `s'
What is the version of libnotify-devel your using ? - Chenthill. On Fri, 2006-01-06 at 21:27 -0500, Lee Revell wrote: On Fri, 2006-01-06 at 20:20 -0500, Lee Revell wrote: On Sat, 2006-01-07 at 01:33 +0100, Andre Klapper wrote: hi lee, Am Freitag, den 06.01.2006, 13:58 -0500 schrieb Lee Revell: Cannot build HEAD: [...] How can I work around this bug? take a look at the patch available at http://bugzilla.gnome.org/show_bug.cgi?id=325574 Thanks. I found a workaround, if you cd to the right directory and paste the sed comand into the terminal it works and you can just run make again. But now it fails here: make[7]: Entering directory `/smb/rlrevell/cvs/evolution-newnew/evolution/calendar/gui/alarm-notify' if gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -DG_LOG_DOMAIN= \evolution-alarm-notify\ -I../../.. -I../../../widgets -I../../../calendar -DEVOLUTION_GLADEDIR= \/usr/local/share/evolution/2.6/glade\ -DEVOLUTION_LOCALEDIR= \/usr/local/share/locale\ -DEVOLUTION_LIBEXECDIR= \/usr/local/libexec/evolution/2.6\ -DORBIT2=1 -pthread -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/local/include/libgtkhtml-3.8 -I/usr/local/include/evolution-data-server-1.6 -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libgnomeprintui-2.2 -I/usr/include/gnome-vfs-module-2.0 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -MT alarm-queue.o -MD -MP -MF .deps/alarm-queue.Tpo \ -c -o alarm-queue.o `test -f 'alarm-queue.c' || echo './'`alarm-queue.c; \ then mv -f .deps/alarm-queue.Tpo .deps/alarm-queue.Po; \ else rm -f .deps/alarm-queue.Tpo; exit 1; \ fi alarm-queue.c: In function 'popup_notification': alarm-queue.c:1463: error: 'NotifyIcon' undeclared (first use in this function) alarm-queue.c:1463: error: (Each undeclared identifier is reported only once alarm-queue.c:1463: error: for each function it appears in.) alarm-queue.c:1463: error: 'icon' undeclared (first use in this function) alarm-queue.c:1474: warning: implicit declaration of function 'notify_icon_new_from_uri' alarm-queue.c:1514: warning: implicit declaration of function 'notify_send_notification' make[7]: *** [alarm-queue.o] Error 1 make[7]: Leaving directory `/smb/rlrevell/cvs/evolution-newnew/evolution/calendar/gui/alarm-notify' make[6]: *** [all] Error 2 make[6]: Leaving directory `/smb/rlrevell/cvs/evolution-newnew/evolution/calendar/gui/alarm-notify' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/smb/rlrevell/cvs/evolution-newnew/evolution/calendar/gui' make[4]: *** [all] Error 2 make[4]: Leaving directory `/smb/rlrevell/cvs/evolution-newnew/evolution/calendar/gui' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/smb/rlrevell/cvs/evolution-newnew/evolution/calendar' make[2]: *** [all] Error 2 make[2]: Leaving directory `/smb/rlrevell/cvs/evolution-newnew/evolution/calendar' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/smb/rlrevell/cvs/evolution-newnew/evolution' make: *** [all] Error 2 Lee ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] exchange connector question
You can do that through Evolution-data-server. There was some discussion regarding communication with EDS, you can find those mail threads here http://mail.gnome.org/archives/evolution-hackers/2005-October/msg00070.html. thanks, Chenthill. On Sun, 2005-11-27 at 16:21 +0100, Ron Arts wrote: Hello all, We need to build a linux commandline program that can plan a meeting in an exchange server calendar, given a startdate, and report back the date/time that the meeting will take place. Is there anyone that can give me a headstart on this? Maybe there are example programs, testprograms for the connector somewhere? I couldn't find a testsuite in the ximian-connector sources. If someone is wiling to build this for us under contract please contact me with a quote. thanks, Ron Arts ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
