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

List:       kde-pim
Subject:    Re: [Kde-pim] libkcal amendments for email alarms
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-11-28 18:57:01
[Download RAW message or body]

On Thursday 28 November 2002 13:44, David Jarvie wrote:
> On Thursday 28 Nov 2002 8:02 am, Cornelius Schumacher wrote:
> > On Thursday 28 November 2002 03:55, David Jarvie wrote:
> > > Additionally, KAlarm needs to be able to store some stuff
> > > specific to it in alarms, so I propose to add an
> > > X-KDE-KALARM-TYPE property to the VALARM component in iCalendar.
> >
> > Please don't add Kalarm specific code to libkcal. If you really
> > need custom parameters please implement a generic way to access
> > these. Something like "setCustomParameter( const QString &app,
> > const QString &key, const QString &value )".
>
> I'm not sure about the 'app' parameter - is it necessary to have the
> application specified at all? When reading from the calendar, any
> custom properties which were set for other applications would be
> updated in the Alarm instance but would then simply be ignored by the
> client application. When writing to the calendar, custom property
> values in the Alarm instance should only exist for the client
> application, so no properties specific to other applications should
> be written. If you insist on a test for the application identity,
> presumably we would have to use
> kapp->aboutData()->appName() ?

The app parameter is only to define a clean namespace. Otherwise you 
could accidently overwrite parameters from other apps. We should also 
make sure that unknown custom parameters get written back.

> Add the following methods to Alarm:
> ===================================
>
> void Alarm::setCustomCalendarProperty(const char *key, const QString
> &value) {
>   if (strcmp(key, "X-KDE-KALARM-TYPE") == 0)
>     mKAlarmType = value;
> }

The function should better be called setCustomProperty(). The "Calendar" 
is redundant.

> QMap<QCString, QString> Alarm::getCustomCalendarProperties() const
> {
>   QMap<QCString, QString> properties;
>
>   // KAlarm-specific stuff
>   if (!mKAlarmType.isEmpty()) {
>     properties["X-KDE-KALARM-TYPE"] = mKAlarmType;
>   }
>   return properties;
> }

"Qstring customProperty( const QString &key )" would be better. I don't 
think we need a map of all parameters.

In addition to that I wouldn't like to see KAlarm specific code in 
libkcal. libkcal should stay a generic iCalendar library. Why don't you 
store the data in a generic way?

Are you sure that you need the custom property. Storing custom data in 
iCalendar should ve avoided wherever possible. This isn't good for 
interoperability. You can always store the data separately and 
reference it by the unique ids.

> I think that we should also implement a similar mechanism for
> Incidence. Currently, calendar files all contain kpilot-specific
> properties which really shouldn't be there unless the calendar has
> been written by kpilot.

Agreed.

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://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]