[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:       David Jarvie <lists () astrojar ! org ! uk>
Date:       2002-11-29 21:51:34
[Download RAW message or body]

On Friday 29 Nov 2002 8:16 am, Cornelius Schumacher wrote:
> Have a look at libkabc nad KAddressBook and how it handles custom
> properties. This is the way I would also consider useful for libkcal.

Ah - now I understand.

> That's exactly what I meant. Are you sure about the QCString argument? Does
> iCalendar define the property names to be something different than utf8?

Yes, you're probably right since iCalendar is by definition in UTF8 format.

> > I don't see why custom properties should harm interoperability any more
> > than storing data in separate files. After all, RFC2445 allows custom
> > properties, and they shouldn't interfere with any application which
> > doesn't know how to interpret them. For such an application, the
> > information is simply missing, just as if it had been written into a
> > separate data file. And I'd much rather have all the data in a single
> > calendar file than have to mess about with a second file. Obviously what
> > I say applies primarily if the custom properties contain only a small
> > amount of data - the balance might tip towards a separate data file if
> > there was a lot of extra data to store.
>
> In many cases custom properties aren't necessary, because the same
> information can also be stored using the standard properties. If that is
> possible it's certainly preferable because other programs get a chance to
> also handle the information.

Unfortunately there are few standard properties in VALARM, and they leave 
little scope for storing anything other than the absolutely basic stuff 
essential to every alarm.

> An additional problem is that in many cases custom properties store
> information of the view, not the document. For example if you store a
> screen position in the calendar file, you might get weird results, if you
> open the file on another computer with a smaller display. For this kind of
> information it's better to store them locally. KOrganizer even has a class
> for that (DocPrefs). Maybe we should move this to libkcal.

What I want to store are a couple of extra statuses which are nothing to do 
with the view.

> Finally, have you ever tried to load a file containing custom properties in
> KOrganizer and save it again? All custom propeties are lost. Ok, this is a
> bug, but I'm not sure that other programs don't behave the same.

Rather, we should make sure that libkcal doesn't lose custom properties, by 
adding functions such as are being proposed here.

Below are my revised suggestions which I believe comply with all the points 
which you have raised. I suggest implementing the custom property methods so 
that every property name is automatically formed as X-KDE-APP-KEY where APP 
represents the application name, and KEY represents the application's 
individual tag for that property. This would adhere to RFC2445's 
recommendation that a code for the vendor should preferably follow the 
initial X-.

Add the following methods to Alarm:
===================================
/** Create or modify a custom calendar property. */
void setCustomProperty(const QString &app, const QString &key,
                       const QString &value);
/** Delete a custom calendar property. */
void removeCustomProperty(const QString &app, const QString &key);
/** Return the value of a custom calendar property. */
QString customProperty(const QString &app, const QString &key) const;
/** Initialise the alarm's custom calendar properties to the specified
 *  key/value pairs. */
void setCustomProperties(const QMap<QString, QString> &properties);
/** Return all custom calendar property key/value pairs. */
QMap<QString, QString> customProperties() const;

In ICalFormatImpl::writeAlarm(), add:
=====================================
QMap<QString, QString> custom = alarm->customProperties();
for (QMap<QString, QString>::Iterator c = custom.begin();  c != custom.end();  
++c) {
  icalproperty *p = icalproperty_new_x(c.data().utf8());
  icalproperty_set_x_name(p,c.key().utf8());
  icalcomponent_add_property(a,p);
}

In ICalFormatImpl::readAlarm(), add:
=====================================
QMap<QString, QString> customProperties;
while (p) //// get_next_property loop:
  ...
  case ICAL_X_PROPERTY: {
    QString value = QString::fromUtf8(icalproperty_get_value_as_string(p));
    customProperties[QString::fromUtf8(icalproperty_get_name(p))] = value;
    break;
  }
}
....
ialarm->setCustomProperties(customProperties);

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