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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
