[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-03 19:33:38
Message-ID: 200507032033.39013.lists () astrojar ! org ! uk
[Download RAW message or body]

On Sunday 03 Jul 2005 14:45, Reinhold Kainhofer wrote:
> Am Samstag, 2. Juli 2005 10:38 schrieb David Jarvie:
> > Recurrence::endDate() - this returns a date-time value, so its name isn't
> > very intuitive, suggesting as it does that it returns a QDate.
>
> Everything in recurrences works with QDateTime, and I didn't want to use
> "DateTime" all over the place, when the only place that really only uses a
> QDate is the method to get all recurrences times for a given day, and one
> convenience method.

I wonder if something like the Event class method dtEnd() might be a better 
name, since it seems more neutral about what it's returning (even if the "dt" 
bit might suggest a date-time, but it's not that clear). I'm just not 
convinced by a method called endDate() returning a date-time.

> > There are some new QPtrList members to hold RecurrenceRules. Given that
> > QValueList is more compatible with Qt4, wouldn't it be better to use
> > QValueList<RecurrenceRule*> to ease the pending transition?
>
> That would mean that I also implement auto-deletion for them...

It's up to you. As long as it works now, that's the main thing.

> > It looks as if the compat code is being removed. If so, I don't think
> > that it should be, since there must be people still using fairly old
> > versions of KDE PIM who will benefit from this code when they eventually
> > upgrade.
>
> No, the code is not removed. Rather, it's now done in the proper libkcal
> way by a class CompatPre31 derived from the Compat class (after the loading
> is finished and before the class is used).

I hadn't looked at the code in the other libkcal classes. If it's implemented 
in a Compat class, I'm happy.

> From what I saw in the old 
> compat code, which was spread out all over the recurrence class, the only
> problems were:
> -) floating events were one day too short (i.e. an all day event on July 3
> needs to go from July3 0:00 until July 4 0:00, while pre-3.1 it had July3
> 0:00 until July 3 0:00).
> -) rDuration was set to the number of time periods to occur, not the number
> of actual occurences (with a special error in the weekly case).
> -) dates of the year were stored as year day with a special case for leap
> years.

Yes, I think that those were the only things which needed to be corrected for.

> On a side note: I see that kalarm does its own compat functionality, and
> the libkcal CompatFactory doesn't check for kalarm's prodid. So all errors
> by wrong implementations in libkcal will not be caught by the libkcal
> compat code.

KAlarm uses a few custom properties and categories in the calendar, and it's 
mainly those which it checks for in its compat code. I don't think that 
application-specific code really belongs in a common library. In fact, having 
said that, I wonder whether KOrganizer code belongs there either? Should each 
application's compat code not perhaps be implemented as virtual methods in 
its own classes inherited from libkcal's Compat class, or something along 
those lines?

> Proably we shall switch our prodids to something of the form 
> PRODID:-//KDE//NONSGML KOrganizer 3.5 pre (libkcal 3.5 pre)//EN
> instead of our current
> PRODID:-//K Desktop Environment//NONSGML KOrganizer 3.5 pre//EN
>
> The advantage would be that libkcal could detect the libkcal version and
> correct problems with previous libkcal versions, while we can also correct
> wrong usage of libkcal in applications.

Seems a good idea.

> > KAlarm's coding convention is to have no spaces inside round brackets.
>
> Okay. I'm just so used to the libkcal and korganizer style that this
> happens automatically. Will change.

Thanks.

Cheers,
David.
-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html
_______________________________________________
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]