[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:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2005-05-28 22:43:45
Message-ID: 200505290043.52010.reinhold () kainhofer ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Am Samstag, 28. Mai 2005 18:10 schrieb David Jarvie:
> 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.

yes, that's what I'm trying to do. Once the event is loaded (or created in the 
editor), all you have to do is call getNextDate, and you'll get the next 
occurence (after all rdates and rrules have been used and all exceptions have 
be excludeded). 

> > 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.

Well, by default it would be an infinite recurrence. So just calling 
setWeekly(2) would mean an infinite recurrence on the same weekday, forever. 
Only if you want to bound the recurrence, then you'll need to call 
setDuration or setEndDate. I'm including a comment on that in the doxy-docu 
of the methods, of course.


> > 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. 

This additional complexity, however, will not be available through the 
Recurrence class. For that you'll have to use the new RecurrenceRule class:
RecurrenceRule *rrule = event->recurrence()->defaultRRule();
rrule->setByDate(...);
rrule->setByDay(...);
rrule->setByWeekNumber(...);

On the other hand, simple things like the old rMontlyPos are still possible 
(and the applications still use that kind of thing):
event->recurrence()->setMonthly( 4 ); // for every 4 months
event->recurrence()->setMonthlyPos( 

Basically, for the old stuff, the Recurrence class will still provide an 
interface to the settings of the first RRULE. So there won't be much change 
(just syntactic change, not semantic) for application developers. What was
  Recurrence *r = event->recurrence();
  if (count)
    r->setMonthly(Recurrence::rMonthlyDay, freq, count);
  else if (end.isValid())
    r->setMonthly(Recurrence::rMonthlyDay, freq, end);
  else
    return false;
  r->addMonthlyDay( 13);

will now become:

  Recurrence *r = event->recurrence();
  recurrence.setMonthly( freq );
  if (count)
    recurrence.setDuration( count);
  else if (end.isValid())
    recurrence.setEndDate( end);
  recurrence.addMonthlyDate( 13 );

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).


> > 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, 

I'm thinking of adding ways to add custom types, which have a name (shown in 
the radion button group) and a widget (shown on the right, derived from a 
common base class of all minutely/hourly/daily/weekly/monthly/yearly/atlogin 
config widgets).

> and to omit KOrganizer's "Appointment Time" group box

Yeah, that's a minor issue.

> 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.? 

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. 
Currently you can only exclude one whole day. currently, if you have an 
hourly alarm, but don't want it to happen today at 4pm, you'll have to turn 
it off for the whole day.

> 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.

the shapes are not so different. The difference is that in korganizer the 
other tabs in the editor are much wider, so the recurrence tab seems to be 
much wider...


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?

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]