Re: kdereview: events runner
On Friday 27 August 2010 22:22:29 John Layt wrote: On 24 August 2010 22:06, Aaron J. Seigo ase...@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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kdereview: events runner
On 24 August 2010 22:06, Aaron J. Seigo ase...@kde.org wrote: hi .. the events runner has been in kdereview for a while now and it is time to decide what to do with it :) Alexey: if there are no known issues with it, please move it into kdeplasma- addons/runners/ kdeplasma-addons has no hard restrictions on coding style, but we do encourage the use of kdelibs style so that there is an ease of switching between plugins for all plasma developers. it is up to you, however. 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 ... cheers :) Interesting, haven't seen that before. A few comments after a quick look, I can get more specific later. 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). 2) It uses Boost shared pointers, shouldn't it be using a Qt equivalent? 3) The code is a bit messy, it needs some polishing to kdelibs standard. 4) I don't think variantToDateTime() and dateTimeToVariant() are needed anymore, KDateTime is now a proper QMetaType so will work seamlessly with QVariant. 5) The DateTimeRange and DateTimeParser classes have far more methods in them than actually get used in Event, either trim back to only what is needed, or look to move to kdelibs where it can be used in a general case, but it would need a lot of work, e.g. data members are currently public and accessed directly rather than via get methods. 6) The date/time input formats are not localised, i.e. are not what the user expects to be able to enter. You should try use the standard KLocale read date/time functions, don't try reinvent the wheel. If only a fixed format is possible then ISO format would be preferred using KDateTime methods. 7) Have you tested timezones work properly? In short, I don't think it's ready yet. I'd be happy to work with Alexey in a few weeks to use his code to develop a Service for this based around the existing calendar DataEngine. Cheers! John. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
