[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-29 13:30:48
Message-ID: 200505291430.48542.lists () astrojar ! org ! uk
[Download RAW message or body]

On Saturday 28 May 2005 23:43, Reinhold Kainhofer wrote:
> Am Samstag, 28. Mai 2005 18:10 schrieb David Jarvie:
> > > 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.
>
> That's basically the new thing: Every possible combination is acceptable.
> So if you have a recurrence on every friday, you can add a monthly date
> (say the 13th, so that the event will only occur on all fridays that are
> the 13th). You can than even add e.g. a week number (let's say in calendar
> week 2, so the event will only occur on a friday the 13th if it's in
> calendar week #1. This means it will only occur on Jan 13, 2006; jan 13
> 2012; Jan 13 2017; etc.) RFC 2445 is really general about these things, and
> I try to implement everything that rfc 2445 allows.

All I'm really asking for is for the doxygen comments to make it clear when an 
extra element of the combination operates as a logical AND, and when it 
operates as an OR. Presumably all options in a single RRULE are ANDed, and if 
you want to OR things, you need to use separate RRULEs, RDATEs, etc.

> As you see, I try to keep as much of the old code structure available, only
> add a very flexible backend for recurrence calculations, and clean up some
> code-cruft.
>
> And the recurrence()->recurrenceType() will still return the usual "old"
> enum values: rMonthlyPos (if monthly and BYDAY are given), rMonthlyDay (if
> MONTHLY [and BYMONTHDAY] are given), rYearlyPos (if YEARLY and BYMONTH and
> BYDAY are given), rYearlyMonth (if YEARLY and BYMONTH [and BYMONTHDAY] are
> given), rYearlyDay (if YEARLY and BYYEARDAY are given). If an unknown
> combination is set in the RRULE, rOther is returned, which indicates that
> the RRULE cannot be expressed in the old terms of minutely / hourly / daily
> / weekly / (monthly|yearly)by(day|pos|month).

The main thing, now that the recurrence code is being rewritten, is not to 
hinder any improvements just in order to maintain compatibility with the old 
interface. I for one don't mind altering KAlarm if it means that we'll have a 
better and saner Recurrence class.

> Exactly. I'd like to add rdates, maybe (if it doesn't blow up the UI)
> multiple rrules (selectable via a combo box at the top). And add times to
> exdates.

That would be a really useful improvement.

> BTW, I think that if we allow copying the recurrence object I think
> kalarm's code can already simplified a lot. Why wasn't this possible so far
> anyway? Just because of the IncidenceBase *mParent pointer?

I seem to remember that that was the reason.

Cheers,
David.
_______________________________________________
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]