Re: Akonadi Calendar Dataengine
Hi all, I landed a first version of the data engine in playground now (it's a copy of the calendar one). Please let me know if it works for you - it should automatically start akonadi, but unless you have something in your akonadi calendar, it won't work. And it should work with KDE 4.4 afaict. It's compatible with the old calendar one, so just install it and you shouldn't notice a change. Requests to it have to have the form: calendar:-mm-dd:-mm-dd where the two dates are a range. Currently you might get some events that are not in the range due to things like recurrence making it not easy to correctly filter in some cases. I'd be happy if anyone would write a quick calendar list plasmoid as example, it could simply show a list of dates and the corresponding event. Greetings, Frederik Aaron J. Seigo wrote: On April 5, 2010, Frederik Gladhorn wrote: Calendar - this one uses queries like isHoliday:region:date and gives i think this is the one that should be extended. it was always the intention to do so, in fact. :) For my purpose I'd rather use a date range to query calendar events. So I'd suggest parameters like: * start date (maybe like the current Calendar engine - iso: -mm-dd) * end date * optional a filter for types - this can be one of: event/todo/journal - is this useful? Returned would be maps with: start date-time, end date-time, summary, long description, location and type sounds good. Is anyone up to changing the current calendar? It would need at least more sure; i know that code reasonably well (not the original author, however :) and it should be very easy to do. Let me know if this is desirable, which data engine to change and then I'm hoping for cool new todo list plasmoids and an extended calendar for the clock for TODOs, see the todo runner in kdereview. Next step would of course be adding a service as well in order to add new calendar events. yep; DataEngine::serviceForSource ftw :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 6, 2010, Frederik Gladhorn wrote: Requests to it have to have the form: calendar:-mm-dd:-mm-dd where the two dates are a range. could we replace calendar: with events:? another concern is that if you have two calendars viewing similar data, the data won't get shared. e.g. if one calendar is viewing march and the other one april, it would be nice if the DataEngine would not duplicate the dates on each side of march and april (to show spill over between the two months). would it be possible instead (additionally?) to support: events:2010:week50 this would mean the calendar would have to request 6 sources instead of 1 in many cases, but it would ensure the data is shared as much as possible. it would also mean that when switching from march to april, only 4 weeks of data would need to be fetched instead of 6. I'd be happy if anyone would write a quick calendar list plasmoid as example, it could simply show a list of dates and the corresponding event. i'd rather just plug it right into the actual calendar. it's not hard. let's work out the above details and then i'll work on adding it to the clock calendar. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
Aaron J. Seigo wrote: On April 6, 2010, Frederik Gladhorn wrote: Requests to it have to have the form: calendar:-mm-dd:-mm-dd where the two dates are a range. could we replace calendar: with events:? sounds good to me (done) another concern is that if you have two calendars viewing similar data, the data won't get shared. e.g. if one calendar is viewing march and the other one april, it would be nice if the DataEngine would not duplicate the dates on each side of march and april (to show spill over between the two months). would it be possible instead (additionally?) to support: events:2010:week50 this would mean the calendar would have to request 6 sources instead of 1 in many cases, but it would ensure the data is shared as much as possible. it would also mean that when switching from march to april, only 4 weeks of data would need to be fetched instead of 6. Yes, we just need to decide on a good format. Internally it uses models that akonadi supplies and the filtering is done by using a proxy model, so we're quite flexible. If possible I'd like to use some values that KDateTime can easily use, so that no special date parsing is needed. I imagine weeks feel awkward to work with, so how about just using months? That is what the holiday calendar currently does. Calculating which week a certain date corresponds to is not difficult but I bet it leads to confusion somewhere. The holiday syntax looks like this: holidaysInMonth:de:2010-04-01 where you can in fact put in anything for the day value and you'll get back the holiday dates for the month. So would eventsInMonth:2010-04-01 sound OK? I don't have strong feelings about this. Also is there some way to know when a data source is no longer needed? Or does that only happen when the data engine is deleted? I'd be happy if anyone would write a quick calendar list plasmoid as example, it could simply show a list of dates and the corresponding event. i'd rather just plug it right into the actual calendar. it's not hard. let's work out the above details and then i'll work on adding it to the clock calendar. I still think a plasma-akonadi-todo list would be easy to write and nice to have (I'm not overly fond of the plasma calendar looks). Cheers Frederik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 6, 2010, Frederik Gladhorn wrote: So would eventsInMonth:2010-04-01 sound OK? I don't have strong feelings about this. yes, that'd be cool as well, and keep it consistent with holidays. events:2010-04-02 could then return the events for just one day? would that make sense? Also is there some way to know when a data source is no longer needed? Or does that only happen when the data engine is deleted? even better, it happens automatically when the source is no longer connected to any visualization. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
Hi, Aaron J. Seigo wrote: On April 6, 2010, Frederik Gladhorn wrote: So would eventsInMonth:2010-04-01 sound OK? I don't have strong feelings about this. yes, that'd be cool as well, and keep it consistent with holidays. events:2010-04-02 could then return the events for just one day? would that make sense? Sure, no problem. I'll finish that tonight. Also is there some way to know when a data source is no longer needed? Or does that only happen when the data engine is deleted? even better, it happens automatically when the source is no longer connected to any visualization. My question was for the individual requests within one engine. But even more important: What if I get a second sourceRequestEvent() for the same source string? Do I have to call setData() again or will the old values be returned from cache without my intervention? Cheers Frederik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 6, 2010, Frederik Gladhorn wrote: What if I get a second sourceRequestEvent() for the same source string? Do if the source already exists, it won't get called again. sourceRequestEvent is *only* called when the source does not exist. once it exists, calls are made to updateSourEvent as needed (e.g. due to a connected visualization requesting a polling interval when calling connectSource). the DataEngine may also decide to update the source on its own. there are a few issues i see in the current code in playground: a) eventData[StartDate] = model-index(row, Akonadi::CalendarModel::DateTimeStart).data().toDateTime().toString(); that last toString() probably isn't needed. puting the QDateTime object in there is just fine. b) this is in akonadiCalendarSourceRequest, but it should be in initAkonadiCalendar (to avoid multiple connections): connect(m_calendarModel, SIGNAL(rowsInserted(QModelIndex, int , int )), this, SLOT(calendarModelRowsInserted(QModelIndex,int,int))); c) when a source is requested, akonadiCalendarSourceRequest is called. this creates a new Akonadi::DateRangeFilterProxyModel and that remains around for the lifetime of the engine. what i'd recommend here is creating a subclass of Plasma::DataContainer that has the Akonadi::DateRangeFilterProxyModel as a member. then in sourceRequetEvent, the engine could just do something like: initAkonadiCalendar(); addSource(new AkonadiDateRangeSource(name, start, end)); return true; this hypothetical AkonadiDateRangeSource class would subclass Plasma::DataContainer, call setObjectName(name) in its constructor, connect the signals to itself which call setData() on itself as appropriate and then setNeedsUpdate() (which schedules the signals for the visualizations that are connected). this way, when the source goes out of use (e.g. all the visualizations disconnect from it) then the Akonadi::DateRangeFilterProxyModel would also get deleted. it would also move all of the Akonadi code related to the events date ranges out into its own class (nice for code clarity) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
Marco Martin wrote: On Monday 05 April 2010, Frederik Gladhorn wrote: Hi all, I just noticed that now - with KDE SC 4.4, I have a working Akonadi Calendar. Which by itself is pretty awesome of course. But wouldn't it be even ++aweseome if that was connected to my plasma-clock-foldout-calendar? not only awesome, is a mst have :) So I set down and poked our pimsters and got all the info I need in order to write a data engine for the calendar. I'm good to go on the Akonadi part. Now I'd like to have a few comments: There are two data engines that could be extended towards this. Or I could start a new one of course... Calendar - this one uses queries like isHoliday:region:date and gives information about individual holidays. (btw - it seems completely undocumented, so you'd need to look into the source in order to find out what valid requests are. Is not using api dox a good idea? Or is it documented somewhere else?) The other one is the Akonadi dataengine which doesn't care about calendars yet. On the other hand it already links to Akonadi. It has emails, microblogging and contacts as data. This one uses ContactCollection-id so the separators are ':' and '-'. I guess there is no rule about this at all, so every data engine just comes up with it's own string concatenation scheme? i think the akonadi dataengine would be the place to go For my purpose I'd rather use a date range to query calendar events. So I'd suggest parameters like: * start date (maybe like the current Calendar engine - iso: -mm-dd) * end date * optional a filter for types - this can be one of: event/todo/journal - is this useful? also in the query the time could be useful (for plasmoids that show more detailed data than the calendar for instance), perhaps a qdatetime? it would be in the results with time anyway. but I can include that in the query as well. Returned would be maps with: start date-time, end date-time, summary, long description, location and type Is anyone up to changing the current calendar? It would need at least more colored squares and tooltips (which would also be nice for the current holidays). not sure for 4.5, probably not, but can be done yes (if somebody is willing to take it earlier would be happy tough :p) dude, I want this, now! :P (yeah, I know I should do this myself then, but I only want the data engine part of the task...) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 5, 2010, Marco Martin wrote: The other one is the Akonadi dataengine which doesn't care about calendars yet. On the other hand it already links to Akonadi. It has emails, microblogging and contacts as data. This one uses ContactCollection-id so the separators are ':' and '-'. I guess there is no rule about this at all, so every data engine just comes up with it's own string concatenation scheme? i think the akonadi dataengine would be the place to go i disagree; DataEngines should be topical (e.g. Calendar), not based on the technical underpinnings (comes from Akonadi) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Akonadi Calendar Dataengine
On April 5, 2010, Frederik Gladhorn wrote: Calendar - this one uses queries like isHoliday:region:date and gives i think this is the one that should be extended. it was always the intention to do so, in fact. :) For my purpose I'd rather use a date range to query calendar events. So I'd suggest parameters like: * start date (maybe like the current Calendar engine - iso: -mm-dd) * end date * optional a filter for types - this can be one of: event/todo/journal - is this useful? Returned would be maps with: start date-time, end date-time, summary, long description, location and type sounds good. Is anyone up to changing the current calendar? It would need at least more sure; i know that code reasonably well (not the original author, however :) and it should be very easy to do. Let me know if this is desirable, which data engine to change and then I'm hoping for cool new todo list plasmoids and an extended calendar for the clock for TODOs, see the todo runner in kdereview. Next step would of course be adding a service as well in order to add new calendar events. yep; DataEngine::serviceForSource ftw :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
