[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - April 20 - 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] New 'eclient' branch in eds
On Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote: 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. Thanks for posting this, Milan. I want to emphasize how important these new APIs are and ask everyone to look it over and provide comments. I had a sneak peek at this over the weekend and jotted some notes. So far I've only reviewed in detail the client-side headers because that's what I'm most concerned about getting right. The rest of it can be tweaked and changed as needed -- even the backend APIs are never truly frozen. But the client-side APIs *will* be frozen, since that's what other projects will be migrating to and attempting to use. The new client-side APIs are: EClient (abstract base class) http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-client.h?h=eclient ECalClient (replaces ECal) http://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal-client.h?h=eclient I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information for multiple users at a time and the results appear in a iterative fashion. The freebusy information of some users are delivered first, while the server keeps fetching other user's free/busy information. So if we could have he FreeBusy api such as this, we could leverage those features, ECalClientFreeBusy e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t start, time_t end, const GSList *users, GCancellable *cancellable, GError **error); (with a async counter-part) Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar *user, GSList *ecalcomps) The clients could watch for the signal and update the freebusy information as and when they receive from eds. - Chenthill. EBookClient (replaces EBook) http://git.gnome.org/browse/evolution-data-server/tree/addressbook/libebook/e-book-client.h?h=eclient ECredentials (authenication) http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-credentials.h?h=eclient I'll split my comments into two posts so this doesn't get too overwhelming. Simple, hopefully non-controversial stuff here and meatier topics in a separate post. Overall I'm pretty happy with the APIs. * There's some overlap between the new EClient API and the new ESource API that I'm working on. Some functions will need to be dropped once the new ESource API is in place, so I don't know if you want to do this now or wait. ESourceList is being removed so obviously any functions involving ESourceList will be dropped: e_client_util_get_system_source() e_client_util_set_default() e_client_util_get_source_for_uri() e_cal_client_get_sources() e_book_client_get_sources() We will no longer refer ESources using URIs. We will only refer to ESources by their unique ID string. So the following functions will be dropped: e_client_get_uri() e_cal_client_new_from_uri() e_book_client_new_from_uri() Default sources will be tracked using the new ESourceRegistry API, so the following functions will be dropped: e_cal_client_set_default() e_cal_client_set_default_source() e_book_client_set_default() e_book_client_set_default_source() There's a few functions that I think are too trivial to keep in light of the lookup capabilities of ESourceRegistry. I'd like to keep the EClient APIs as slim as possible initially and drop these functions: e_cal_client_new_system() Instead do: source = e_source_registry_lookup_by_uid (registry, system); client = e_cal_client_new (source, source_type, error); e_cal_client_new_default() Instead do: source = e_source_registry_get_default_calendar (registry); client = e_cal_client_new (source, E_CAL_SOURCE_TYPE_EVENT, error); (similar functions exist for tasks and memos) e_book_client_new_system_addressbook() Instead do: source = e_source_registry_lookup_by_uid (registry, system); client = e_book_client_new (source, error); e_book_client_new_default_addressbook() Instead do: source = e_source_registry_get_default_address_book (registry); client = e_book_client_new (source, error); * We should use GIO error codes whenever possible, and I see quite a bit of overlap here. I think following error codes should be dropped: E_CAL_CLIENT_ERROR_SUCCESS E_BOOK_CLIENT_ERROR_SUCCESS There's no need for an error code for successful operations. E_CAL_CLIENT_ERROR_INVALID_ARG E_BOOK_CLIENT_ERROR_INVALID_ARG Use G_IO_ERROR_INVALID_ARGUMENT. E_CAL_CLIENT_ERROR_BUSY E_BOOK_CLIENT_ERROR_BUSY Use G_IO_ERROR_BUSY.
Re: [Evolution-hackers] EWS MessageInfo leak wtf
On Sat, Apr 9, 2011 at 4:08 AM, David Woodhouse dw...@infradead.org wrote: ==5510== 41 bytes in 1 blocks are possibly lost in loss record 8,473 of 17,762 ==5510== at 0x4A05E46: malloc (vg_replace_malloc.c:195) ==5510== by 0x3B6A048B52: g_malloc (gmem.c:164) ==5510== by 0x3B6A06101D: g_strdup (gstrfuncs.c:102) ==5510== by 0x1693D7B1: ews_message_info_clone (camel-ews-summary.c:75) ==5510== by 0x1693E4FD: camel_ews_summary_add_message_info (camel-ews-summary.c:417) ==5510== by 0x16940ADD: camel_ews_utils_sync_created_items (camel-ews-utils.c:973) ==5510== by 0x16939819: sync_created_items (camel-ews-folder.c:660) ==5510== by 0x16939B41: ews_refresh_info_sync (camel-ews-folder.c:750) ==5510== by 0x4C78C99: camel_folder_refresh_info (camel-folder.c:1156) ==5510== by 0x33B6E7F0F7: mail_msg_proxy (mail-mt.c:469) ==5510== by 0x3B6A06BBC3: g_thread_pool_thread_proxy (gthreadpool.c:319) ==5510== by 0x3B6A069445: g_thread_create_proxy (gthread.c:1897) ==5510== Can't repeat it; don't know how it happened... except of course that it obviously happened when SyncFolderItems returned some created items. The frame in ews_message_info_clone() at camel_ews_summary:75 is setting mi-change_key on the newly cloned MessageInfo: http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l75 (I'm also *sure* it happened after commit 17bd5273 in which I fixed a consistent leak of our mi-change_key by adding a message_info_free() method to our class. Not only do I remember it that way, but the timestamp of my valgrind log file is about four hours later than that commit, and the *other* valgrind warnings that the -change_key leak caused are noticeable in their absence.) I'm confused by the use of camel_message_info_clone() in the first line of camel_ews_summary_add_message_info(): http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l417 There is *one* caller of this function, and it's the one in the above backtrace — camel_ews_utils_sync_create_items(): http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-utils.c#l973 And that *creates* a new MessageInfo of its own... which AFAICT never gets freed, although valgrind doesn't seem to be complaining about that, and I don't know why. Removing the clone in camel_ews_summary_add_message_info() and just using '(void *)info' seems to work just as well; I'm not really sure what's going on here. And either way, I've never been able to repeat the above warning. Chen, was there a reason for the clone? And why isn't valgrind complaining about it? Can anyone see something that would cause the above complaint that it *did* make? The ews_summary_clone seems un-necessary there. I picked up some code from the imapx provider and certainly did a mistake there. The const identifier for the CamelMessageInfo in the signature of the function and message_info_clone can be removed. - Chenthill. -- dwmw2 ___ 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 improvements for MeeGo
On Tue, Apr 5, 2011 at 2:51 PM, Patrick Ohly patrick.o...@gmx.de wrote: On Di, 2011-04-05 at 13:06 +0530, Chenthill Palanisamy wrote: On Mon, Apr 4, 2011 at 6:24 PM, Patrick Ohly patrick.o...@gmx.de wrote: Hello! I have published some more information about our plans for MeeGo: http://wiki.meego.com/Architecture/planning/evolution-data-server http://wiki.meego.com/Architecture/planning/evolution-data-server/eds-improvements I was going through the eds-improvements part of it. In the performance improvement mentioned at 'Optional parsing of data in the client'. I was wondering if having a new lib[ecal/ebook] api that can return two kind of meta data, + one for populating the view [similar to message-info in mailer] + for querying the changed information [mentioned at 'change tracking+ atomic updates' section'. I don't quite follow. Can you be more specific? I was suggesting to pass the summary-info required for the view as a dbus object (which requires creation of an object similar to CamelMessageInfo) which could save string-vcard convertions and vice-versa in eds and also remove the need for delayed parsing. But as I do not understand the use case, the suggestion may not even be relevant.. I just noticed that e_book_get_book_view() already has a GList *requested_fields parameter. Is that used and/or implemented anywhere? The special case relevant for a QtContacts bridge would be to get just the UID. I don't think that this is covered by the current file backend, but at least the libebook/D-Bus/backend API should be in place to implement it. Ok this gives me some idea. But, use cases would make things clear. - Chenthill. Thick clients like evolution can still use the existing apis to avoid much changes unless there is a significant improvement in performance.. Maybe good to have some profiling data as well ? I have asked my colleagues working on the contacts app in MeeGo about use cases they care for. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ 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] Maintenance fork for Evolution / EDS 2.32
On Mon, Apr 4, 2011 at 12:23 PM, Milan Crha mc...@redhat.com wrote: On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: That's great; thanks. I'll do a little more testing on the patches I've cherry-picked into my trees, and then unless someone else has objected in the meantime I'll push them. Hi, I objected against this many times, directly to you, on IRC, with no effect, obviously. If I recall correctly, the reason why release-team decreased releases is that distributions were *not* using .2 release. Which is just the opposite you are trying to convince us. If they are not using official releases, why should they use unofficial branch? By the way, how would you look for a fix user reported to your distribution, as a distribution maintainer? The work-flow, as I understand it, is like this: a) user enters a bug report in your distro bugzilla b) maintainer gathers enough information to identify the issue c) check upstream bugzilla for a duplicate or possible fix d) decide on the change whether backport or indicate will be fixed in the next stable/unstable release Note that I do not expect anyone looking into git branch for a particular fix, with a very good reason, they would rather check in bugzilla, which offers much better searching ability and contains enough information for possible bug matching, with compare of git commit. And the bugzilla should have enough information about the fix, like either a patch or a link to particular commit. The evolution-related products use to it that way. This would certainly help distributions which want to stay with Evolution 2.32 for a while.. My only concern here is, while cherry-picking patches how would we take care of the translations and documentation ? Are we adhering to the freezes in the gnome-2-32 branch (am not calling this a latest stable branch) ? If the documentation and translations are taken care of, should the freezes matter ? - Chenthill. That's my opinion. Bye, Milan P.S.: as of today (or tomorrow, if you wish), the official stable release is 3.0.0. ___ 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 - Mar 23 - 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] Sqlite cache for address-book storage in EDS
On Mon, Mar 14, 2011 at 3:53 PM, Adam Tauno Williams awill...@opengroupware.us wrote: On Mon, 2011-03-14 at 10:09 +0530, Chenthill Palanisamy wrote: On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes mbar...@redhat.com wrote: Okay, this might be a long shot but I'm gonna throw it out there anyway: would it make sense to look at using Xapian to index a directory of raw vCards? Am not sure if its worth doing this for adress-book. Am just making an assumption that the address-book content may not be as huge as mail data. The only address-book data that would be large enough would be GAL (exchange) and SystemAdressBook (groupwise). This is a self-fulfilling prophecy; I and others have tried to have large address books... which doesn't work... so address books remain small. I agree, the *only* should be removed from the third sentence of mine, there could be other address-books. While thinking of Xapian for address-book, am not still convinced. One could search on various fields such as sender, subject, recipients, full-text search etc. in mailer often and xapian is said to work much better. Although I have not got any profiling information as such, but its just from hearing from multiple people. But for address-books, the most often used searches would be based on name and email. Even if the address-book has 21k or more data, a db with good indexing should perform better. The information stored will be small when compared to mail content.. Well these are just my observations, are there any other cases am missing ? I have a CardDAV/GroupDAV collection of ~21,000 contacts I'd love to have access to via Evolutions WebDAV address book. But anything more than a thousand or so gets to be unbearably slow. AFAIR, there are some UI issues involved here which should be dealt with separately. - 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] Branch date?
On Tue, Mar 15, 2011 at 3:07 AM, Matthew Barnes mbar...@redhat.com wrote: It's getting to be branching time again. I think in the past we've usually branched when the hard code freeze starts, which would be next Monday. Shall we go with that again or does anyone have a desire to branch sooner? Am fine with branching on Monday after the hard-code freeze.. - Chenthill. (Speaking for myself, I don't really have anything ready to land yet.) ___ 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] Sqlite cache for address-book storage in EDS
On Thu, Mar 10, 2011 at 6:54 PM, Matthew Barnes mbar...@redhat.com wrote: On Thu, 2011-03-10 at 08:13 +0100, Milan Crha wrote: do not forget that the DB cache is compiled conditionally, because some distros do not ship libdb. Using SQLite for this was mentioned months ago, only no-one got time to actually do it, so go for it. Also, as far as I know there is still licensing issues between Berkeley DB's Sleepcat license and [L]GPL, which is how libebackend was born. https://bugzilla.gnome.org/show_bug.cgi?id=465374 I'm +1 on dumping Berkeley DB. Only think of two things: - using binary storage for this kind of data is bad for cases where the binary file breaks, either due to an update/downgrade of the library providing access to it, or just by a crash. It's not so hot with camel as SQLite has there only summary data, but if you want to store also real data in it, then it can be a problem. There are people having issues recovering their data from addressbook storage already, but if you are going to do any change on it, then it would be good to think of that from the beginning. It would be good to store raw vCards in some plain text file(s) which will be indexed by SQLite summary. This plain text file(s) will be then easy to import to evolution if something goes wrong, and with erasing SQLite file user will not loose any valuable data. (I'm thinking of a flat maildir approach here.) Milan raises a good point about binary formats versus text. Would be good for the raw data to remain human readable. Yes, it makes senses to store it that way. If we can index the data in sqlite summary and store VCards in the way we store individual mail data, it should be sufficient.. Okay, this might be a long shot but I'm gonna throw it out there anyway: would it make sense to look at using Xapian to index a directory of raw vCards? Am not sure if its worth doing this for adress-book. Am just making an assumption that the address-book content may not be as huge as mail data. The only address-book data that would be large enough would be GAL (exchange) and SystemAdressBook (groupwise). I think sqlite should suffice in indexing this.. We've been talking about moving to notmuch [1] for mail indexing, and notmuch is built on Xapian. Trying out Xapian for address books might be a good test drive for using it with mail. To be honest, I wont be having that much time for testing this for address-book. Jony was trying to evaluate the performance between sqlite and notmuch mail indexing for mails, any updates there Jony ? - Chenthill. The catch is, Xapian is written in C++. So we'd likely have to hand write our own GObject bindings for it in C. That's what makes it a long shot. But we could look to notmuch even WebKit/GTK+ for examples of binding C++ to C. My C++ is rusty but I still have my Stroustrup text book. [1] http://notmuchmail.org/ ___ 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] Sqlite cache for address-book storage in EDS
Hi, I was going through the Address-book cache used in EDS while starting to write the address-book backend for EWS. We use EBookBackendCache that stores in the form of xml, EBookBackendDBCache which uses libdb for storing the VCard strings. While EBookBackendSummary stores the information about names, email ids for faster lookup. Some backends use EBookBackendCache and some use EBookBackendDBCache. ldap, google, webdave uses EBookBackendCache. file, groupwise, exchange uses EBookBackendDBCache. I was wondering if its worth writing a EBookBackendSqliteCache as we are already using sqlite for string emails and later migrating all backends to use the same. The summary and VCard strings can be stored in a single Cache without the need for using EBookBackendSummary. Any thoughts ? - 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 - Feb 16 - 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] [Reminder] Evolution community meeting at #evolution-meet channel - Feb 16 - 3:30 PM UTC
On Mon, Feb 14, 2011 at 10:51 PM, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2011-02-14 at 21:18 +0530, vikas ruhil wrote: can tell in more detail about Meeting ? i want to participate in meeting ? so please tell ? See: http://projects.gnome.org/evolution/meetings.shtml We should add some boilerplate text to these meeting announcements that includes the above link to the meeting log archives. Will put in a detailed information in the wiki and add it to the meeting announcements. By the way, Chen, I won't be able to attend this week. If you or Milan could send me the log I'll get it posted. Sure, will send you. - 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] (no subject)
On Wed, Feb 9, 2011 at 7:40 PM, thilagaraj thilak tk.thilaga...@gmail.comwrote: sir, i'm really interested in studiying linux, but i experienced in windows environment. sir,please tell me first of all what can i do for got experienced in Linux environment with basics. sir,unfortunately i joined evolution-hackers in gnome.org.but i can't understand what they do and their purposes?, i'm doing B.E(cse) fulltime 3rd year.my long day dream in my life is to play in linux like windows environment.please please help me to achieve my dream as well as my goal. This is not a right forum to ask about contributing to linux and understanding linux. Anyways you can find a lot of sources by just googling. Checkout, http://live.gnome.org/JoinGnome http://en.wikipedia.org/wiki/Linux http://www.linuxforums.org/ I would encourage you to look listinfo and its archives to understand what a particular mailing-list is meant for before proceeding with your queries. - Chenthill. Thank you sir!... ___ 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] cleaning up the timezone handling mess
On Tue, 2008-04-15 at 18:07 +0200, Patrick Ohly wrote: On Tue, 2008-04-15 at 13:59 +0530, chenthill wrote: To preserve the timezone history, the best way would be to store the old rules in VTIMEZONES which should be done in libical. If I understand you correctly, you are suggesting to merge a VTIMEZONE with TZID=FOO that comes with a new meeting invitation with a previously stored VTIMEZONE with the same TZID, so that the merged VTIMEZONE has the rules from both the original VTIMEZONE. The problem is that incoming VTIMEZONE definitions from Exchange do not contain information to which year the rules apply. In the examples that I quoted, both use DTSTART:16010101T02 and thus are mutually exclusive. Nope I don't mean merging here. The VTIMEZONE from libical currently do not provide the history of timezone changes (older + current rrules) for the system timezones. Libical should be modified so that the VTIMEZONE's generated stores the timezone history. The Tzfile would have the history stored on the system, libical just does not store it in VTIMEZONE. Say if a meeting is received from exchange server with some Tzid for America/New_York. As we discussed below, this needs to be mapped to system timezone and libical should provide the VTIMEZONE which has the timezone history. This way, we need not use the VTIMEZONE sent by exchange and still display the older/current events properly. I do not recommend having another set of tzid's with versions in it for maintaining the old rules. This would trigger the comparison of rules between different versions of timezones. I don't get this part. Can you elaborate what you mean? Are you saying that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts with an existing VTIMEZONE should be avoided? yes, if libical is modified to return VTIMEZONE with the history and once mapping between foreign timezones to system timezones is done at the backend, this is would not be required. All the older events would be properly displayed. Once the outlook timezones are mapped with libical ones, the libical timezones which would have the old rules can be used. Mapping foreign TZIDs to system timezones always should be attempted first. Storing a VTIMEZONE under a different name is only the fallback. [VTIMEZONE and VEVENT are added separately] I don't think it works like that. iirc the whole VCALENDAR (used as top-level component in itip-formatter) which has events and timezone gets passed to the backend, the backend adds the timezone and events to the cache, notifies the UI. After looking at the Evolution source code I already came to the same conclusion. However, clients like SyncEvolution do add VTIMEZONE and VEVENT separately. That is necessary because the UID of each new VEVENT is required immediately, which is not possible (or at least very awkward) via ecal_receive_objects(). I hope SyncEvolution is the only backend which does it in this way. SyncEvolution is not a backend. It is a client program using the synchronous libecal API. Ah ok. I misunderstood that it has a corresponding external backend as well. I believe OpenSync works the same way, although I haven't looked at it during the last two years. I am not sure if we would need a libecal API for this. Is it not possible to handle it inside e_cal_backend_add_timezone? No, because the call cannot return the information to which TZID the timezone was mapped. Modifying the icaltimezone *zone would be an API change. The tzid need not be changed for the VEVENT. The following would work fine even if VTIMEZONE and VEVENT are handled separately, e_cal_backend_add_timezone - Add the timezone to backend's cache if the timezone cannot be matched with the system timezone else do not add. e_cal_backend_get_timezone - use the mapping and provide proper system timezone or if its unable to map, it needs to get the timezone from the cache. The clients can now use the corresponding libecal API's to get the right timezone. So, I feel this can be done commonly to all backends at EDS. Yeah you can get the code after two weeks, not a problem. Please file a bug on this since the old bug is about, outdated evolution timezones which is obsolete now as we pickup the timezones from the system. The bug also has a too many comments already. Probably we can also schedule a meeting on irc and have a discussion on this. Please let me know the time which would be suitable for you. I'll create a new bug report. Should we move the discussion away from this list? I think if we discuss this on IRC, we can conclude on the design faster. It would be better to do the patch reviews in bugzilla. Usually we could meet on IRC during the evening CEST, but there's not much time this week. I may not be available over next week. Let me know a suitable time during this week or after April 28th. - Chenthill.
Re: [Evolution-hackers] ESourceGroup from ESource
On Wed, 2006-07-19 at 18:09 -0700, Scott Herscher wrote: How does one derive an ESourceGroup from an ESource? If I call e_source_peek_group() with a valid ESource instance, and then immediately call E_IS_SOURCE_GROUP(), I am getting false. Was the ESource got from ESourceList ? If so, ESourceList object should be alive while accessing the ESource, otherwise ESourceGroup would be NULL if the corresponding ESourceGroup was not ref'ed. - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal functions
On Wed, 2006-07-19 at 11:25 -0400, Teresa Thomas wrote: Hi I have one last (hopefully) question about libecal. I want to add a VEVENT to an existing Evolution calendar. Hence, I created an iCalComponenent to be added and hope to use the e_cal_create_object(ECal* eCal,iCalComponent iCalcomp, char** uid, char** error) function. Now, I understand that eCal is a calendar client. If I want to add my event to an Evolution calendar, what exactly should eCal contain? Is it some sort of an identity of a cal? If so, how can I obtain it. ECal client can be obtained by using the function e_cal_new, by passing an ESource. ESource holds the settings required for a calendar client which is stored in gconf. The client is associated with the backend through the protocol specified in the uri stored in ESource. Eg: uri starting with file:/// would refer to file backend, contacts:// would be pointing to contacts backend. - Chenthill. Thanks! On 7/19/06, Teresa Thomas [EMAIL PROTECTED] wrote: Thanks Mr Palanisamy! My Bad, I actually meant to ask about the function e_cal_component_new() in ECalComponent.h/c. Anyway, from what I understand it returns an ECalComponent, which is an (easier to manipulate) wrapper around an iCalComponent. On 7/19/06, chenthill palanisamy [EMAIL PROTECTED] wrote: On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas wrote: Need some assistance in my quest to comprehend EDS. What exactly is the difference between e_cal_create_object() [in ECalComponent] and e_cal_create_object() [in ECal ] ? e_cal_create_object is used to create a appointment, task or a memo object (ECalComponent) in the corresponding backend (file, http, groupwise etc). There is no function named e_cal_create_object in ECalComponent. There is a function e_cal_component_get_created which gives the creation date of a ECalComponent. Please have a look at http://www.go-evolution.org/EDS_Architecture . - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal functions
On Tue, 2006-07-18 at 17:44 -0400, Teresa Thomas wrote: Need some assistance in my quest to comprehend EDS. What exactly is the difference between e_cal_create_object() [in ECalComponent] and e_cal_create_object() [in ECal ] ? e_cal_create_object is used to create a appointment, task or a memo object (ECalComponent) in the corresponding backend (file, http, groupwise etc). There is no function named e_cal_create_object in ECalComponent. There is a function e_cal_component_get_created which gives the creation date of a ECalComponent. Please have a look at http://www.go-evolution.org/EDS_Architecture . - Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exposing Evo calendar events
On Sun, 2006-07-16 at 16:24 -0400, Teresa Thomas wrote: Thanks Andre, I have been looking at that EDS architecture details but it just gives a general picture. I am having starting troubles with EDS. Just so I can get started, does anyone have any sample code that exposes the events/tasks of an evo calendar? Have a look at the clock applet code which queries the events/tasks from EDS and shows it. http://cvs.gnome.org/viewcvs/gnome-panel/applets/clock/ or the alarm daemon which queries for the events that has alarms for the current day. http://cvs.gnome.org/viewcvs/evolution/calendar/gui/alarm-notify/ cheers, chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
