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

List:       kde-pim
Subject:    Re: Some notes and questions
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-09-22 15:05:06
[Download RAW message or body]

#if Mirko Sucker
> Two notes here:
> 1) The delivery label is used for shipping something, unfortunatly I do not know an english
> word for that, the German one is, for example, "Postfach" (PO box?).

I would have assumed that 'delivery label' meant a whole address, formatted
in such a way that it could easily be printed onto a sticky label.

PO box is Post Office Box, numbered boxes used for anonymous delivery,
generally by large companies or barely-legal operations.

> 2) In general, the minimal amount of fields we should support are the vCard fields. You
> cannot even import Netscape addresses without that, so it makes no sense to exclude any
> field in this standard. BTW, most of them are more reasonable than one might think at the
> first glance.

This isn't really relevant to our GUI. Any importing of fields is a filtering
issue, so should be addressed while writing each filter. Check out the vCard
filter in the kab2 dir to see how it's done (I doesn't work at the moment,
because it needs to know the names and structure of fields.. which is
what we're discussing here)

> In German it is "Herr Dr. Meier". That means, both are needed. In the first versions of
> kab, I did not support all of this fields. But it makes sense.

Did you read my other mail where I said we should simply use a QLineEdit and
stop worrying about it. It's less work to type 'Dr.' rather than press
'<down><down><down><enter>'

> > ... > This is supposed to hold military ranks, for example. I am a soldier.
> > Let's let this be nonstandard.
> 
> Isn't there this kind of "civil ranks" in your language (like "senior engineer")? I am not
> sure about this.

Usually called 'occupation' or 'profession', rather than rank, 'occupation'
being what you do for a living, and 'profession' being what you are trained
as, but don't necessarily work as at the moment.

I, for example, would be 'Senior UNIX Administrator', while my sister would
be 'Student'. UNIX admin is my profession, not what I'm doing right now, so
I suggest 'profession' is better. That's en_GB anyway. Don't know about en_US.

> It is important to see what this "Formatted name" is good for. For example, if you have a
> chinese friend, the program might display its name completly wrong, as first and last name
> are in reverse order. Now, you give the correct "one line name" in Formatted name, and you
> have the option, at least, to get the program displaying it right.

Yes, no point in spending your time doing fancy stuff like auto-filling in
parts where there's likely to be differences according to locale. KISS, as
they say.

> The functionality is not the same. There are subtle differences. Consider using groups to
> order people in enterprises. Now you want to set who of them are VIPs. Add "VIP" as a
> keyword to the persons - they are in different groups, possibly.

Hmm. If you want to put someone in a group, do it. An 'Entity' can be a member
of many 'Group's.

> > It would be great to have a list of fields/names we have agreed on.
> >
> > I want to clear up a couple of things. Currently I have prefixed most field
> > names by "X-", maybe we should just drop this prefix?
> 
> Or add it at all places. Is there a reason for it except being used to it by mime-types?

Mimetypes added by KDE are prefixed with x-kde-. We could follow this convention
or use something like x-kab-. Whatever.

> I am working on it. Possibly it is no good idea to (only) post it here. How about a
> definition in the pim module?

Yes. Did you read my message talking about a text file, with a description
of the format that would suit ? Just do a draft and dump it in CVS, then we
can change it.

> Another thing:
> Is there a general way for storing the key-value-pairs we spoke of? If not, I have one that
> is really flexible (a completely Qt-based derivate of the one used by kab). It is able to
> store the alues directly to ASCII files, either in a tree structure or plain, and support
> different basic data types. How about it?

ASCII is not really a good plan when you have arbritrary data. We can't even
use ASCII to store 'plain text', as the default is text/unicode, which may
be 16-bit (actually, may even be 32-bit in future). Forget about ASCII if you
want an internationalised addressbook.

All the GDBM backend does is take a <QString,QByteArray> pair, and use the
string as the key. If you wanted to do this with a text file, you'd have to
encode the string _and_ the byte array. A text file full of pairs of base64 -
encoded data isn't really fun to work with :)

Cheers,
Rik

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