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

List:       kde-pim
Subject:    Re: [Kde-pim] the goal of kaplan
From:       Anders Lund <temp_and () tiscali ! dk>
Date:       2002-10-16 22:35:16
[Download RAW message or body]

On Wednesday 16 October 2002 13:09, Tobias Koenig wrote:
> On Tue, Oct 15, 2002 at 10:48:50AM +0200, Anders Lund wrote:
> > On Monday 14 October 2002 11:57, Tobias Koenig wrote:
>
> Hi,
>
> > > No good idea. If we'll use real data instead of QStrings we'll have to
> > > write converter (data<->string) because we have to make sure, that the
> > > data can be stored in a vCard or LDAP tree. This converter has to be
> > > put into a layer above libkabc, since moving this code to the lib would
> > > make the lib bloating and difficult to extend.
> >
> > On the other hand, if each application wanting to use a binary format of
> > a data would have to provide it's own conversion, we would easily get
> > inconsistensy, and bloat too.
>
> We can only store entities that exists in the vCard specification.
> Please keep that in mind!

He, someone said that the vCard format was not limiting... I even think that 
that person was right, as if I understand things correctly we can add a 
property to a field.

> > Plus, it the addressbook knows what kind of
> > data a field should contain, it can help promoting that (by checking and
> > providing a proper input widget).
>
> Exactly, and then somebody comes and want a wounderfull listview input
> widget with green columns and red rows...
> We can't provide all input widget in the lib, so we shouldn't start with
> such exceptions!

If that is bitching about you beeing unhappy with me working on anything 
within kaddressbook at all, please let me know. I'll just back out then. 
And... A listview is not an input widget. Providing proper input widgets is 
saving users from frustration. Personally I *hate* having to enter dates into 
kaddressbook, as it refuses to accept my local format, that is if I type 
"d[d]/m[m] yyyy" it claims that that is not a valid date. And I have yelled 
*loudly* several times at outlook back in my windows days, because it refuses 
to provide proper input options.

> Text/Date input is enough.

Allthough I agree dates are important and also complex to enter, that is a 
subjective preference. What do you have against numbers, for example?

> > > We'll add it in 3.2 again but i would vote for string-only fields.
> > > (Ok, maybe time fields, but no more types, because you can input
> > > everything as string)
> >
> > many applications may want to use booleans, numeric types etc. See above.
>
> The user puts in a '1' or 'false' and the code which use this input
> have to convert it to a integer or whatever it needs. This converting
> is really not part of the library.

So, a field value can only be used by an application that knows what to expect 
from it and implements conversion. That is about one client application to 
use a field, as only who added the field will have the full understanding of 
it's purpose.

-anders
_______________________________________________
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]