[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] New Recurrence code for libkcal
From:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2005-05-28 16:10:17
Message-ID: 200505281710.17472.lists () astrojar ! org ! uk
[Download RAW message or body]

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<RecurrenceRule> inside the Recurrence class), but for
> the application developer the Recurrence class will still be the right
> interface to recurrences.  <snip>  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: <snip>

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<int>, which I'd like to change to
> QValueList<int>. 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/
[prev in list] [next in list] [prev in thread] [next in thread]