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

List:       kde-pim
Subject:    Re: [Kde-pim] [PATCH] Recurrences
From:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2005-07-02 17:54:19
Message-ID: 200507021854.19912.lists () astrojar ! org ! uk
[Download RAW message or body]

On Friday 01 Jul 2005 00:39, Reinhold Kainhofer wrote:
> Here is the patch for libkcal, which implements recurrences much better:
> http://www.fam.tuwien.ac.at/~reinhold/KOrganizer/RecurrenceRule/
>
> 4) Changes in the recurrence rule don't trigger the event's update yet. I
> don't want to pass the Incidence* pointer to the recurrence rule (I'd like
> to keep the recurrence issues completely separated from the incidence
> class)... If we get rid of the Incidence* pointer, we can safely add
> copying for recurrences and then I suppose kalarm could get rid of several
> hundred lines of code, which just implements copying of recurrence data...

Allowing copying of a Recurrence object would definitely be useful.


A couple of further comments about recurrence.h:

Is it really sensible to remove the variants of methods such as 
setRecurStart(), durationTo(), etc., which take a 'const QDate&' parameter. 
This is a more logical way to do things for recurrences which float, and also 
for non-sub-daily recurrence types when you're really interested in the date 
rather than the time. For example, to find the number of recurrences up to 
and including a certain date, you would have to call
      durationTo(QDateTime(date, QTime(23:59:59))
instead of simply
      durationTo(date).
I can't see any real disadvantage of retaining these QDate versions, and they 
do bring extra convenience for people using the class.

In recurrence.h, change "setYearlyByDate" in a Doxygen comment to 
"addYearlyDate".

How about changing the parameter names in recurrence.h from "_r*" to something 
less obscure? I've always wondered why these names were used, and now seems a 
good time to, for example, change "short _rPos" to a simpler "short pos".

I haven't checked other classes yet - hopefully if there are any faults, they 
will reveal themselves soon. As for the KAlarm patches, I'm happy for you to 
commit them (preferably changed to KAlarm coding conventions), and I'll 
scrutinise them soon.

Well done for putting in the effort to tidy up recurrence handling - it 
certainly looks like an improvement.

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]