kdereview: events runner
John Layt
johnlayt at googlemail.com
Sun Aug 29 18:23:07 CEST 2010
On Friday 27 August 2010 22:22:29 John Layt wrote:
> On 24 August 2010 22:06, Aaron J. Seigo <aseigo at kde.org> wrote:
> > other than that, it would be a very nice feature to do something like:
> > "events today" or "events tomorrow" and get a list of them back ...
Forgot to mention this is easily done using the Calendar DataEngine.
> 1) The runner directly interfaces with Akonadi, shouldn't the update parts
> be moved into a Plasma Service? (Yes, I'm supposed to be looking at moving
> the Calendar DataEngine into a Service but I'm doing fieldwork right now
> and won't have time for a few more weeks).
I found a little time and I've committed a first pass at the .operations file
for the Service to
workspace/plasma/generic/dataengines/calendar/calendar.operations. It defines
a minimal simple set of ops for adding Events/Todos/Journals, I'm still not
convinced advanced ops like recurrences should be done through the Service
method but rather done directly using Akonadi widgets.
I'm assuming the source for the service will be the Akonadi::Collection for
the Event/Todo/Journal to be added to, and a lot of the logic to talk to
Akonadi and return the result will go into a CalendarServiceJob class.
Just wondering if it's possible in the .operations kcfg file to nest complex
structures, have multiple occurrences for the same entry, or use Akonadi
enums? For example an Attendee has a name and e-mail and role etc and there
can be several attendees, or their are allowed values for Status or Secrecy.
What's the best way to handle these?
> 2) It uses Boost shared pointers, shouldn't it be using a Qt equivalent?
I think the boost pointers are used by Akonadi as I can't see any code
actually defining them directly? If so you shouldn't need to include them
directly, just use the Akonadi includes/typedefs instead.
A couple more comments:
The CompleteTodo and CommentIncidence actions take the Event/Todo Summary as
the key for the incidence to update, but not only is this potentially a very
long string and prone to mis-typing, it is also optional and not guaranteed to
be unique so is not a good choice for the key. The only unique and guaranteed
key is the collection id and incidence id, but I'm not sure that's a user-
friendly choice so updating these via a runner might not be a good idea?
You also assume Incidences should be added to the default Collection, which is
a reasonable assumption in most cases, but prevents people adding to other
Collections (e.g. a remote or group calendar), you should try to find an
optional syntax to allow users to include the Collection they want.
Cheers!
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100829/166636ce/attachment.htm
More information about the Plasma-devel
mailing list