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 & Canada) / Tijuana: > 20060801T103000 > CLASS:PRIVATE > ORGANIZER:MAILTO:[EMAIL PROTECTED] > TRANSP:TRANSPARENT > DTEND;TZID=(GMT-08.00) Pacific Time (US & Canada) / Tijuana: > 20060801T113000 > RRULE:FREQ=DAILY;COUNT=5;INTERVAL=1 > SEQUENCE:2 > EXDATE;TZID=(GMT-08.00) Pacific Time (US & 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 & Canada) / Tijuana: > 20060801T103000 > CLASS:PRIVATE > ORGANIZER:MAILTO:[EMAIL PROTECTED] > TRANSP:TRANSPARENT > DTEND;TZID=(GMT-08.00) Pacific Time (US & 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
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
[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] 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
Cool, thanks for the clarification. gtk_init() is definitely simpler! Have fun, Peter On 7/26/06, Ross Burton <[EMAIL PROTECTED]> wrote: > On Tue, 2006-07-25 at 19:19 -0400, Peter Colijn wrote: > > 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: > > libgnome is being deprecated, so unless you have a massive requirement > to use GnomeProgram, the gtk_init (&argc, &argv); will be sufficient. > > Ross > -- > Ross Burton mail: [EMAIL PROTECTED] > jabber: [EMAIL PROTECTED] > www: http://www.burtonini.com./ > PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.2 (GNU/Linux) > > iD8DBQBExyAsLQnkR9C0M98RAq9cAKCLLo61+X3fqJhRm+mrpPVRSGzTtwCgtSuo > 4O6PeWcsqSPQKnth0MbGhzo= > =7vYN > -END PGP SIGNATURE- > > > ___ 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
#include
#include
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, 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
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
[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
