Akonadi PIM in the Plasma Calendar

[John Layt]

Hi pimsters and plasma-wranglers(?),

Just a follow-up on where this is now.  

After Akademy I managed to finish off my changes to the calendar data engine 
to enable recurring and multi-day incidences to be treated correctly.  
Basically I deleted much of what was already there and started again.

This still required copying files from kdepim/akonadi/kcal which now live in 
their own directory 
kdebase/workspace/plasma/generic/dataengines/calendar/akonadi along with a 
README explaining the what and why:

  calendar_p.h
  calendar.h
  calendar.cpp
  calendarmodel.h
  calendarmodel.cpp
  calfilterproxymodel.h
  calfilterproxymodel.cpp
  utils.h
  utils.cpp

If anyone makes bug-fixes to those classes in kdepim could you also apply them 
to kdebase, or at least ccmail: me so I can keep them in sync?  Thanks.

The CalendarEngine now returns almost all the Event/ToDo/Journal attributes 
for all Incidences that occur within the requested date range, as well as a 
list of all the Recurrences for each Incidence within the requested date 
range.  Only Attendees, Attachments, Relations, Alarms, Custom Properties, 
Lat/Lon and Collection/Source are not (yet) returned.  The returned data 
structure can be found in 
kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.h.

The problems with the original code resulted from it not being obvious to us 
non-experts that requesting from Akonadi a list of Incidences in a date range 
does not return all the Recurrences in that date range, only the base 
Incidence which gives Start/End Dates for the first Recurrence only which may 
not even fall in the requested date range.  Explicit calls must be made on 
each base Incidence to obtain the Recurrences and their End Dates.  I don't 
think the KCal::CalendarModel::entityData() call even exposes the recurrence 
details at all, hence having to switch to KCal::Calendar class instead.

Any new Akonadi/KCal API intended for use outside kdepim should try to make 
this easier and more obvious to non-experts, i.e. that a one-to-many model is 
needed between Incidences and Recurrences.

Where to next?

Obviously we'll start using the new Akonadi/KCal code once it's in kdepimlibs, 
remove the duplicated code, and add the last few missing fields to the 
returned data.

I think the code needs to move from the Calendar DataEngine into the Akonadi 
DataEngine so they can share a common infrastructure and consistent API 
design.

We'll need to allow the user to configure what Collections/Sources get 
displayed in each plasmoid instance, and to filter within those Collections 
e.g. have work and personal calendars on separate widgets, hide private 
events, disable events if calendar displayed on screen-saver, etc.  Or even to 
turn it off entirely, something missing in 4.5 ;-)

There's probably a lot that can be done to make the display prettier, but I'll 
mostly leave that to the Plasma guys, they're better at that kind of stuff :-)  
Perhaps use html table formatting in the pop-up text to allow proper layout 
and indenting?

The big one will be allowing creating/editing of Incidences.  I managed to 
grab Marco for a couple of minutes just before he left Akademy.  He pointed me 
at Plasma Services which are designed for Plasmoids needing to perform 
updates.  He would prefer that we try implement as much functionality as 
possible using a Service so it is usable by scripted Plasmoids, but did agree 
that advanced/complicated functionality like the recurrence editor might be 
better off used directly rather than being duplicated.  This needs more 
investigation as I don't understand any of it yet :-)  Perhaps I can copy how 
sebas does it in LionMail if it works that way?

Cheers!

John.