[Kroupware] Re: kroupware_branch: kdepim/korganizer

[Cornelius Schumacher]

On Saturday 12 October 2002 22:43, Steffen Hansen wrote:
> * Cornelius Schumacher <schumacher@kde.org> [Oct 12. 2002 19:25]:
> > On Saturday 12 October 2002 03:09, Steffen Hansen wrote:
> > > Actually notes dont map to vCal at all. Or did I miss something
> > > in the spec?
> >
> > We are talking about iCalendar, not vCalendar. It would be very
> > helpful, if you wouldn't mix this up. Martin, I think you should
> > fix the architecture document. It contains a lot of wrong
> > references to vCal.
> >
> > iCalendar defines a journal component. That perfectly fits a note.
>
> Yes, I saw the journal component, but that is for journals, which is
> different from notes.

A journal entry without date exactly corresponds to what KNotes stores 
as note. I don't see any difference here. The journal view of 
Korganizer doesn't show entries without date.

> Is there some kind of "subtype" field or so that I can use to mark a
> vTodo or vJournal as being a note. "Being a note" would mean to be
> ignored by the journal and todo views, and only shown in the notes
> view.

You could use categories to classify todos and journals. For todos you 
could also group todos to be shown by KNotes under a special parent 
todo.

I don't think the application should hide notes from the views of 
KOrganizer, if they are stored as something which can be handled by one 
of the views of KOrganizer. If the user decides to do so that's ok, but 
it might actually quite useful to have different views on notes.

The same is for example true for KArm data. If KArm would store its data 
as iCalendar, KOrganizer could be used as alternative way to show the 
data and provide an easy way to edit it if necessary.

I think sharing common data formats is one of the important things for 
integration of the kdepim apps. This will make it possible to use 
common backends, reuses existing code and gives the user the choice to 
use different applications on the same data just as it fits user 
preferences or requirements of different tasks.

-- 
Cornelius Schumacher <schumacher@kde.org>