Re: [Evolution-hackers] Thanks and some more questions.

2006-08-04 Thread Peter Colijn
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

2006-07-31 Thread Peter Colijn
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

2006-07-31 Thread Peter Colijn
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

2006-07-30 Thread Peter Colijn
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

2006-07-26 Thread Peter Colijn
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

2006-07-25 Thread Peter Colijn
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

2006-04-26 Thread Peter Colijn
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

2006-04-26 Thread Peter Colijn
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

2006-04-21 Thread Peter Colijn
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

2006-03-05 Thread Peter Colijn
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