[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] ical handling library
From:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2004-09-01 17:07:18
Message-ID: 200409011907.22116.reinhold () kainhofer ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


(Sorry for the late answer, but I just came back from a summer academy without 
internet access. For those who don't know me: I'm the new maintainer of 
KOrganizer, with Cornelius being co-maintainer)

On Monday 30 August 2004 21:57, Helge Hess wrote:
> On Aug 30, 2004, at 21:40, Dan Winship wrote:
> > (Our plan was to do something GObject-based, to use the existing GNOME
> > bindings-generating machinery, like we already do for EVCard.)
>
> Hm, so I guess that this will actually happen:
>    GNOME: GObject based iCal lib
>    KDE:   C++ based iCal lib
>    OGo:   Objective-C based iCal lib (already available, but untested)
>
> Since I think that all developers prefer their "own" environment to fix
> the annoying libical issue ;-) Is there any chance (or reason) to avoid
> that and do something together in plain C?

In KDE we currently use libical only as a parser for ics files, and then 
create our own C++ objects from the data that we get from libical. Like 
evolution, we also had to implement the recurrence calculator ourselves 
(although ours is a nasty piece of code and needs to be cleaned up a bit some 
time).

Needless to say that we also ran into several trouble with the 
ringbuffer-approach that libical used...

As far as the discussion about reviving libical goes: Who would be willing to 
actively maintain that code? Besides, I think that libical has some general 
problems with the buffer, which can only be fixed by drastically changing the 
API, and then it might be easier to write a new library. Of course I'd like 
to have one library that will be used by all big PIM applications, 
preferrably in C++ (since that's the way I tend to think). I guess the latter 
will not be possible, so KDE will need another wrapper library around it 
anyway.
This would increase compatibility across all applications using that library, 
and all projects could profit from it. 


> Besides what happens after Evo 2.0, Kontact 3.3 and OGo 1.0 - is there
> any chance to put up a shared "legacy" libical for distributors _now_?

libkcal (KDE's calendar library, which uses libical for parsing and writing 
out ics files) statically links in its own copy of libical.


Cheers,
Reinhold

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]