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

List:       kde-panel-devel
Subject:    Re: Akonadi Calendar
From:       David Narvaez <david.narvaez () computer ! org>
Date:       2011-10-27 20:00:41
Message-ID: CACFh1D5-qmkMWtW-U46gLbyApKahrvctLH-wSdfS7Z8MZyJYiQ () mail ! gmail ! com
[Download RAW message or body]

On Thu, Oct 27, 2011 at 1:36 PM, John Layt <jlayt@kde.org> wrote:
> Hi,
>
> Sorry for not picking up your first email, I've been offline a lot lately.
> Seeing as I'm the one who wrote that README I should fill things in a bit
> more.
>
> The original author of the data engine had to copy the Akonadi interface =
from
> kdepim as it was not available in kdepimlibs at the time. =A0I moved it t=
o the
> subfolder and updated it with some bug-fixes [1] as well as overhauling t=
he
> data engine itself. =A0I'm supposed to be keeping the code in sync but fo=
rgot
> before the last release, so we need to look at refreshing the copy before=
 the
> next release.
>
> The intention has always been to move the Akonadi calendar interface into
> kdepimlibs so everyone could use it, but I don't know if this has been do=
ne
> yet. =A0Once done we can delete the copy and switch the data engine to the
> kdepimlibs version.
>
> Sergio, do you know the status of this?
>
> It was at this point that I was suggesting we might move the code from the
> Calendar engine to the Akonadi data engine so the implementations and
> interfaces are consistent, but thinking about it again Akonadi is an
> implementation detail and a bad name for a high level api so perhaps sepa=
rate
> data engines for Calendar, Mail, and Contacts are better even if they use=
 the
> same underlying code and consistent api.

Well, you knocked me off :)

I think I understand the deal up to this point and I think this is the
migration I was asking about. What comes later is future thoughts on
how to expand the Calendar API, right? If so, I can try Aaron's
suggestion of cloning all kdepim, kdepimlibs and kde-workspace into a
migration mashup, see who gets killed and how, and ping back to the
relevant lists when it's ready for review.

My main concerns are putting the things where they belong (do they
belong anywhere in particular inside Akonadi? or is that yet to be
decided?) and also knowing in advance what other projects in KDE
depend on the Calendar API currently living in kdepim (as it will be
removed and will break those projects) but I guess I can address this
later issue in an e-mail at the general devel list.

Now, who should validate the migration plan and process? Someone at
KDE PIM, right? (I'm including the PIM list again to check on this.)
Thanks for the clarification.

> Currently the Calendar data engine is a one-way affair, it just fetches t=
he
> existing events from Akonadi, you can't use it to add new events. =A0What=
 I
> would like to see happen is a two-way integration using a Plasma service =
[2]
> for which I wrote the initial operations definition file [3] but stalled =
at
> that point. =A0The idea here is not to provide a full api or feature set,=
 as
> creating events is rather complex and Akonadi/kdepimlibs provides advanced
> widgets for doing that which you don't want to be trying to replicate in
> Plasma as well. =A0I think an advanced PIM Plasma widget should link dire=
ctly to
> and use the PIM widgets. =A0What the service would provide is api for add=
ing
> simple events such as one-off reminders for plasmoids that want to integr=
ate
> but are not really PIM specific.
>
> The other big thing that needs investigation is the abiltiy to configure =
what
> Akonadi resource to use, at the moment it just uses the default resource =
but I
> can imagine users might want to show different calendars in different wid=
gets.
> Whether this is something to be provided through the data engine api or if
> it's something an applet should use akonadi directly for is a matter for
> debate.
>
> Basically, as far as I know, no futher work has been done on the Plasma e=
nd or
> the Akonadi end. =A0If you have any more questions, poke me with a stick =
and
> I'll get back to you when I can.
>
> Cheers!
>
> John.
>
> [1] https://projects.kde.org/projects/kde/kde-
> workspace/repository/revisions/master/show/plasma/generic/dataengines/cal=
endar/akonadi
> [2] http://techbase.kde.org/Development/Tutorials/Plasma/Services
> [3] https://projects.kde.org/projects/kde/kde-
> workspace/repository/revisions/master/entry/plasma/generic/dataengines/ca=
lendar/calendar.operations

David E. Narvaez
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]