From kde-pim Sat May 28 16:10:17 2005 From: David Jarvie Date: Sat, 28 May 2005 16:10:17 +0000 To: kde-pim Subject: Re: [Kde-pim] New Recurrence code for libkcal Message-Id: <200505281710.17472.lists () astrojar ! org ! uk> X-MARC-Message: https://marc.info/?l=kde-pim&m=111729665721324 On Saturday 28 May 2005 00:11, Reinhold Kainhofer wrote: > 1) It will be possible to have multiple RRULEs and even EXRULEs. Also, the > exdates and the additional recurrence dates (which wasn't yet implemented > at all, but it will be required as calsify tries to mandate the use of > RDATE instead of RDATE for iCalendar-baseic) will now be handled by the > Recurrence class. Each recurrece rule will be an RecurrenceRule object > (stored in a QPtrList inside the Recurrence class), but for > the application developer the Recurrence class will still be the right > interface to recurrences. One general difference will be that > the Recurrence class already takes care of exception dates, exception > rules, addtional recurrence dates etc. Incorporating exdates, exrules and extra recurrence rules is something which I proposed to do a long time ago, but was dissuaded. It would definitely be cleaner to have them held in the Recurrence object, rather than separately as at present. Then, applications wouldn't have to duplicate code if they wanted to use these RFC2445 facilities. > 2) Currently we have a setting for recurrences on February 29 in non-leap > years with three possible options: on Feb 28, March 1st or not at all in > non-leap years. I'd like to get rid of that, as these three alternatives > can be modelled with the usual recurrence settings: I can live with that - it shouldn't be too difficult to convert KAlarm to use what you propose. > 3) We have a doesRecur() method, which confusingly does not only return if > the event recurrs at all, but also returns the type of recurrence. Even > dfaure asked me once how to find out the type of recurrence, becuase it's > not obvious at all that this is the only way to get the type. Any > objections to turning doesRecur() into a bool, and adding a > recurrenceType() (or just type() ) method to get the type. About half of > the time, doesRecur is used like "if ( event->doesRecur() ) ", so the type > is completely unnecessary there. About time! > 3) Currently we have two version for each set*ly method, one with duration > anf one with end date. e.g. we have > void setWeekly(int freq, const QBitArray &, int duration, int wkStart = > 1); void setWeekly(int freq,const QBitArray&, const QDate &endDt,int > wkStart=1); I'd like to get rid of that argument at all, so that e.g. > setWeekly would be void setWeekly( int freq, const QBitArray &, int > weekStart = 1); void setEndDateTime(const QDateTime &endDateTime); > void setDuration( int duration ); Yes, as long as header file comments point out the need to call these extra methods. > 4) For the monthly and yearly recurrences we have an additional type > argument (rMonthlyPos, rMonthlyDay, rYearlyDay, rYearlyPos, rYearlyMonth), > which is passed to setMonthly and setWeekly. This is actually no longer > needed. It's sufficient to call setMonthly with the frequency, and then add > the position or the day within the month by addMonthlyPos or > addMonthlyDate. Depending on which of these you use, it'll be clear which > type of monthly recurrence it is (actually if you use both, you can add > restrictions like every month on the 13th, but only if it's a friday). This is fine, as long as there are adequate comments in the header file to explain the acceptable combinations and how they work. > 5) Currently we use QPtrList, which I'd like to change to > QValueList. Am I right that with Qt 4 there's no real reason any more > to use QPtrList for integer lists? That would be neater. > 6) I saw that KAlarm uses a recurrence editor, which is basically the same > as in korganizer (with only two additional recurrence types: at login and > minutely/hourly). So I'd like to make a general recurrence editor and put > that into libkcal. Kalarm and KOrganizer can then reuse that. In > particular, extending the UI for recurrences can then be done in libkcal, > and kalarm and korganizer will automatically use the new one. > Is any other application using recurrences? It would need to be configurable to at least allow the extra types of recurrences for KAlarm, and to omit KOrganizer's "Appointment Time" group box. There are a few other differences where I'd prefer to retain KAlarm's approach rather than KOrganizer's. But presumably you might be incorporating various extra possibilities in the editor so as to cater for additional dates, exrules, etc.? I also notice that the two recurrence tabs are very different shapes at present, in order to fit in with the other tabs in their dialogs. I wonder how to approach that in creating a common editor. > Please let me know what you think of these. I'll make the adjustments to > the whole kdepim code anyway, but I'd still like to get feedback from all > persons affected. Generally, what you are proposing sounds like a useful advance on what we have just now. Cheers, David. KAlarm author. _______________________________________________ kde-pim mailing list kde-pim@kde.org https://mail.kde.org/mailman/listinfo/kde-pim kde-pim home page at http://pim.kde.org/