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

List:       kde-pim
Subject:    Re: [Kde-pim] [PATCH] Recurrences
From:       Reinhold Kainhofer <reinhold () kainhofer ! com>
Date:       2005-07-03 22:05:20
Message-ID: 200507040005.21419.reinhold () kainhofer ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Am Sonntag, 3. Juli 2005 21:33 schrieb David Jarvie:
> 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.

Yeah, that's a naming issue. recurStart is also not an ideal name...

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

You're right. It's better to do it properly now, thatn having to fix it again 
when we switch to qt 4.

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

Yes, and no. These things are typically not application specific, but problems 
in libkcal (e.g. libkcal violating the rfc for some issues, like exceptions 
not being included in the duration calculation, etc.). The issue is just that 
the application sets the PRODID, so we need to check for the prodid set by 
the application to find out which libkcal version wrote that file.

That's why I proposed to also include the libkcal version.

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

These compat objects are created by the CompatFactory, before the calendar 
file is actually created from the libical data. To add application-specific 
compat classes would mean to find a good way to hook their creating into the 
existing CompatFactory...

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]