On Tue, 2010-10-05 at 10:41 -0400, Andrew McMillan wrote:
On Tue, 2010-10-05 at 10:58 +0200, Hendrik Helwich wrote:
it is possible to store your own data in the kolab format [1] (Your own XML
Tags and binary mail attachments). So we could preserve the timezone
information from evolution
Am Freitag, 1. Oktober 2010 08:51:44 schrieb Milan Crha:
On Wed, 2010-09-29 at 17:15 +0200, Hendrik Helwich wrote:
So one option for us is to operate on the icalcomponent instead of
ECalComponent.
Hi,
internally yes, but remember, the ECalBackend API uses ECalComponent in
most
On Tue, 2010-10-05 at 10:00 +0200, Hendrik Helwich wrote:
I understand this point for recurring events. In the Kolab format it
is only allowed to store time data in UTC format (see 1.2.1 in [1]).
So we have to think how we can handle this problem in our software.
Hi,
aha, pity they do
Am Dienstag, 5. Oktober 2010 10:20:30 schrieb Milan Crha:
On Tue, 2010-10-05 at 10:00 +0200, Hendrik Helwich wrote:
I understand this point for recurring events. In the Kolab format it
is only allowed to store time data in UTC format (see 1.2.1 in [1]).
So we have to think how we can
On Tue, 2010-10-05 at 10:58 +0200, Hendrik Helwich wrote:
But we still have the problem then that the time in some recurring
events could be shown different in kontact and evolution in winter or
summer time even if both clients are in the same time zone.
Err, right, with respect of
Am Dienstag, 5. Oktober 2010 12:25:06 schrieb Milan Crha:
P.S.: this one might be useful: icaltimezone_get_utc_timezone()
I will check this out. Thanks :-)
Hendrik
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list
On Tue, 2010-10-05 at 10:58 +0200, Hendrik Helwich wrote:
it is possible to store your own data in the kolab format [1] (Your own XML
Tags and binary mail attachments). So we could preserve the timezone
information from evolution iCalendar.
But we still have the problem then that the time
Am Dienstag, 5. Oktober 2010 16:17:42 schrieb Andrew McMillan:
I'm at CalConnect XIX right now with various calendaring people,
lamenting (as we usually do) just how often people seem to think that
storing data in UTC means you can forget the timezone.
Is there any chance of fixing the
On Wed, 2010-09-29 at 17:15 +0200, Hendrik Helwich wrote:
So one option for us is to operate on the icalcomponent instead of
ECalComponent.
Hi,
internally yes, but remember, the ECalBackend API uses ECalComponent in
most cases.
In our project we do not need any time zone information
On Mon, 2010-09-27 at 15:54 +0200, Hendrik Helwich wrote:
while working on a plugin [1] to connect eds to a kolab server, i need to
convert evolution contacts, events, tasks and notes to a kolab email (and
back).
Right now the idea is to use the class EContact for evolution contacts and
Am Mittwoch, 29. September 2010 13:55:51 schrieb Milan Crha:
On Mon, 2010-09-27 at 15:54 +0200, Hendrik Helwich wrote:
while working on a plugin [1] to connect eds to a kolab server, i need
to convert evolution contacts, events, tasks and notes to a kolab email
(and back).
Right now the
Hi evolution hackers,
while working on a plugin [1] to connect eds to a kolab server, i need to
convert evolution contacts, events, tasks and notes to a kolab email (and
back).
Right now the idea is to use the class EContact for evolution contacts and
ECalComponent for evolution events, tasks
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
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
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
Hi there,
On Wednesday 14 July 2010 Ross Burton wrote:
On Wed, 2010-07-14 at 20:14 +0530, chen wrote:
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
On Wed, 2010-07-14 at 20:14 +0530, chen wrote:
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
On Wed, 2010-07-14 at 17:37 +0530, chen wrote:
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
Hi again,
no ideas? Anything?
Best regards,
Christian
--
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/
signature.asc
Description: This is a digitally signed message part.
Hi there,
I'm trying to dig up the EDS data structure which is currently used to hold
calendar data. Searching the sources (among others, evolution-mapi), I found
ECalComponent
being used as a toplevel data structure for calendar data. Regarding this data
structure, I found:
20 matches
Mail list logo
