Re: [Evolution-hackers] Thanks and some more questions.
I'll wager a guess. If you allow UTC EXDATEs, then when the user changes their timezone it's a pain to convert the EXDATE into the new timezone due to DST. So in order to sidestep this headache, it's simply unsupported. I have no idea whether this guess is correct or not :P Have fun, Peter On 8/4/06, Scott Herscher [EMAIL PROTECTED] wrote: Thanks to all that have responded to my questions. I think I've got this e-cal and e-book backend stuff licked at this point. But since I'm writing this...what the hell...I'll ask one more question. I've noticed that Evolution doesn't seem to like UTC specified times in EXDATE or RECURRENCE-ID statements. In other words, this works: BEGIN:VEVENT UID:70209cba-ae85-47e0-bcd0-49cbd70683d4 DTSTAMP:20060804T175402Z X-ZAPPTID:8595 X-ZINVID:8595-8597 X-ZCOMPID:0 SUMMARY:aaa STATUS:CONFIRMED DTSTART;TZID=(GMT-08.00) Pacific Time (US amp; Canada) / Tijuana: 20060801T103000 CLASS:PRIVATE ORGANIZER:MAILTO:[EMAIL PROTECTED] TRANSP:TRANSPARENT DTEND;TZID=(GMT-08.00) Pacific Time (US amp; Canada) / Tijuana: 20060801T113000 RRULE:FREQ=DAILY;COUNT=5;INTERVAL=1 SEQUENCE:2 EXDATE;TZID=(GMT-08.00) Pacific Time (US amp; Canada) / Tijuana:20060802T103000 END:VEVENT And this doesn't. BEGIN:VEVENT UID:70209cba-ae85-47e0-bcd0-49cbd70683d4 DTSTAMP:20060804T175402Z X-ZAPPTID:8595 X-ZINVID:8595-8597 X-ZCOMPID:0 SUMMARY:aaa STATUS:CONFIRMED DTSTART;TZID=(GMT-08.00) Pacific Time (US amp; Canada) / Tijuana: 20060801T103000 CLASS:PRIVATE ORGANIZER:MAILTO:[EMAIL PROTECTED] TRANSP:TRANSPARENT DTEND;TZID=(GMT-08.00) Pacific Time (US amp; Canada) / Tijuana: 20060801T113000 RRULE:FREQ=DAILY;COUNT=5;INTERVAL=1 SEQUENCE:2 EXDATE:20060802T173000Z END:VEVENT I've looked at this for a long time, and it seems like it should work, but Evolution doesn't seem to like it. Anybody have any thoughts? Thanks, Scott ___ 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
[Evolution-hackers] ECalBackend vs. ECalBackendSync
Suppose I am writing a new calendar backend. Which of these two interfaces is preferred? If I implement ECalBackendSync, will operations on the calendar cause the UI to block? Thanks! Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync
Hi Chenthill, On 7/31/06, chenthill [EMAIL PROTECTED] wrote: You would need to implement both. The ECalBackendSync class has a sync lock, which is used if the backend can handle only one operation at a time. It provides the results immediately to the caller. ECalBackend class provides notifications to the client from EDS. Please go through http://www.go-evolution.org/EDS_Architecture for more details. On that page, it says To write a calendar/tasks backend, a subclass of ECalBackend (for asynchronous) _OR_ ECalBackendSync (for synchronous) needs to be written. (emphasis mine) If both need to be implemented, perhaps that article should be updated? I can see how I could implement EBackendSync, then implement EBackend on top of that by having a worker thread that calls the EBackendSync calls. Is that what you're referring to? It depends on how client is designed. Well, my intended client is Evolution :P With Evolution as the client, if I implement ECalBackendSync, will the UI block? Harish mentioned that I could avoid having the UI block if I had a separate thread for repainting. But if I'm just adding a new calendar backend, and I want to use it from Evolution, am I writing any code to do redrawing, etc? I certainly hope not! Thanks! Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Displaying recurrent events in Evolution
Does your implementation of get_static_capabilities say that your calendar backend supports recurrences? Have fun, Peter On 7/30/06, Scott Herscher [EMAIL PROTECTED] wrote: Hey all. I'm trying to get recurrent events working, and while my recurrence rule looks fine, Evolution is only displaying the first instance of the appt in it's UI. It knows that it is a recurrent event, but it's not displaying all the instances of the recurrence. Is there something I'm supposed to do to get Evolution to display all the instances of a recurrence? My recurrence looks like this: BEGIN:VEVENT UID:[EMAIL PROTECTED] DTSTAMP:20060731T001438Z X-ZAPPTID:8254 X-ZINVID:8254-8255 X-ZCOMPID:0 SUMMARY:aaah DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/America/Los_Angeles: 20060731T10 ORGANIZER:MAILTO:[EMAIL PROTECTED] TRANSP:OPAQUE LOCATION:bbb DTEND;TZID=/softwarestudio.org/Olson_20011030_5/America/Los_Angeles: 20060731T11 RRULE:FREQ=DAILY;COUNT=8;INTERVAL=1 SEQUENCE:1 END:VEVENT Also, when I go to edit the event, Evolution won't let me edit the recurrence information. It's all stippled out. Any help you can give would be greatly appreciated. Take care, Scott ___ 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] Creating objects in ECal
Hi Teresa, On 7/27/06, Teresa Thomas [EMAIL PROTECTED] wrote: printf(%d, icalcomponent_is_valid(iCalComp)); prints a 1. BEGIN:VEVENT UID:[EMAIL PROTECTED] DTSTAMP:20060901T1300Z DTSTART:20060401T163000Z DTEND:20060402T01Z SUMMARY:Claudia is in sensitivity awareness class. CLASS:PUBLIC CATEGORIES:BUSINESS,HUMAN RESOURCES TRANSP:TRANSPARENT END:VEVENT Hmm. I'm not entirely sure this is the issue, but I notice that your DTSTAMP is not a proper RFC2445 date-time value; you'd want DTSTAMP:20060901T13Z (i.e. you are missing 2 '0's) The other thing is that in RFC2445, commas need to be escaped with a backslash in values to avoid having them interpreted as a list (perhaps this is not a precisely correct interpretation; someone may well correct me). However, in CATEGORIES, you actually want a list, so in general there is no need to escape any commas. BUT evolution usually does anyway, so you might want to try that just in case :P Hope that helps.. these are just shots in the dark; I haven't tried either of them myself. Have fun, Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Error while trying to obtain ESource list
Hi Teresa,
On 7/25/06, Teresa Thomas [EMAIL PROTECTED] wrote:
(process:4289): GLib-GObject-CRITICAL **: gtype.c:2215: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:4289): GLib-GObject-CRITICAL **: g_object_new: assertion
`G_TYPE_IS_OBJECT (object_type)' failed
Debug: After calling e_source_list_new()
(process:4289): GLib-GObject-CRITICAL **: gtype.c:2215: initialization
assertion failed, use IA__g_type_init() prior to this function
(process:4289): GLib-GObject-CRITICAL **: g_object_new: assertion
`G_TYPE_IS_OBJECT (object_type)' failed
Segmentation fault
I think the issue here is that g_type_init() is not being called.
Generally for gnome programs, the first thing main() should do is call
gnome_program_init, which will call the init()s of a bunch of
libraries and make sure that everything is happy. I can get
e_source_list_new() to not complain with the following code:
#include libgnome/gnome-program.h
#include libgnomeui/gnome-ui-init.h
#include libedataserver/e-source-list.h
int main(int argc, char **argv) {
GnomeProgram * app;
app = gnome_program_init(esourcelist_test, 0.1,
LIBGNOMEUI_MODULE, argc, argv,
GNOME_PARAM_NONE);
ESourceList *esourcelist = e_source_list_new();
g_free(esourcelist);
return 0;
}
Have fun,
Peter
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Google Calendar sync
Hi Harish, Sorry to be a bit slow responding. I am finishing up my degree and moving over the next few days.. :) On 4/22/06, Harish Krishnaswamy [EMAIL PROTECTED] wrote: * Let everybody know you are working on it and pen your thoughts on go-evolution.org. You might attract a few helping hands. I don't have an account here and there doesn't seem to be any way to create one. * The GW calendar backend (which uses GroupWise SOAP APIs) or the http backend would be nice references to model your design on. Great. The Calendar API is XML over HTTP, so while it isn't specifically SOAP, it should lend itself to a similar design. I'm sure the GW code will be a great help. * Let me know how much time/effort you plan to put into this and if you would like it to be added to the 2.8 roadmap. I would like to get a full-fledged plugin working that allows using Google Calendar from Evolution. I'm willing to do it myself, but the problem is that over the next few weeks my schedule is quite erratic as I'm travelling around Asia for a while. I'll be at GUADEC though, and would love to hack on it then. I'll probably get some done before then, but with all the travelling I can't say how much. As for the 2.8 roadmap, I'm not sure. 2.8 will be the GNOME 2.16 release, right? It would definitely be possible to get the backend done by the end of the summer, I'm sure, but I'm not sure how it would fit in to the evolution release schedule and so on. I was planning to just work on it by myself for a while, and then once something is working, solicit suggestions on patches. So that may or may not fit into the 2.8 release timeline. If it lives outside Evolution for 1 release that might not be too bad. Right now I think we should play it by ear. Thanks! Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Google Calendar sync
Hi, On 4/22/06, Armin Bauer [EMAIL PROTECTED] wrote: we had similar ideas about the google calendar. I am workin on the opensync synchronisation framework. The framework already supports a lot of devices and protocols like Evo2, KDE, Palms, IRMC, SyncML and more. So i we would have a google calendar plugin for opensync, we would get instant access to all of these. So i am also very interested in seeing synchronisation with google and would be willing to contribute. OpenSync does indeed sound cool. I think I'd still prefer to have something directly inside Evolution that can talk to Google Calendar, though, to keep things as simple as possible for users. However, I would not be opposed to writing the code in a modular enough way that the Google Calendar parts can be split into a separate library for use in OpenSync. Does that sound ok? Definitely having Google Calendar accessible from OpenSync would be cool for syncing to Palms and such... Have fun, Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Google Calendar sync
Hi, Is anyone working on a way to do 2-way sync with Google Calendar (using the XML-based API)? If not, I'd be interested in doing this. I worked on the Google Calendar team and am quite familiar with the product. I've also done some Evolution work in the past, but it was the 1.4.x days so I imagine things are quite different now. Is this something that could be done in an EPlugin? Or would I need to write a new calendar backend in C? Any pointers or tips as to the best way to do this would be appreciated. Thanks! Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] building evolution-data-server against the already installed libdb
On 3/6/06, Mikhail Zabaluev [EMAIL PROTECTED] wrote: I used to compile e-d-s 1.4 along an external db4.3, by applying a simple patch. It didn't seem to cause any problems. You are of course free to apply your own patches; however, in the long term, using a distribution's version of bdb will probably be an intolerable maintenance burden for either distributors or evolution: So, what's the purpose of bundling an obsolete version of Berkeley DB inside the project? I think the idea was that since the berkeley db API is not very stable, and since distributions ship a wide variety of versions of berkeley db, it would be simpler to ship a version of bdb along with evolution to avoid either (1) requiring distributions wishing to ship evolution to either ship a special bdb just for it, or patch evolution on their own (a big maintenance burden for distributors) or (2) requiring evolution to be compatible against multiple versions of bdb (a big maintenance burden for evolution) Maybe the bdb API is more stable these days so this no longer makes sense; I was under the impression it was still changing quite often. Have fun, Peter ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
