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

List:       kde-pim
Subject:    Re: Some notes and questions
From:       Mirko Sucker <mirko.sucker () unibw-hamburg ! de>
Date:       1999-09-21 19:17:07
[Download RAW message or body]

Don Sanders wrote:

> Number 2 shouldn't be mandatory. For example in the address book GUI I'm
> working on (Kontact)  it's obvious this big hunking multi-line edit widget is
> for entering notes, there is no need to waste space by labeling it "Notes:",
> furthermore if I'm say writing a specialized address book GUI, say um, for
> entering information about people who work in my company then instead of having
> a Company/Organization line edit widget, I might have a combo-box labelled
> "Branch". with options like "Sydney", "Brisbane" ....
> .... I think this is a minor detail. Yeah Organi(s/z)ation sounds ok, better
> even, let's leave this up to the GUI designer though rather than trying to
> force a rigid standard.

Correct.

> The important thing is that we agree on similar names, and the same fields for
> identical attributes.
> .... > Never. How about "Delivery label", field "delLabel"? (Is case important?)
>
> What is this? Can you give an example? Maybe we can make this a nonstandard
> field and I will try to support it in my list of custom fields, please see
> the end of this email for a discussion on custom fields. Let's assume case is important.

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?).
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.

> > Why BusinessAddress?
> No good reason. I did it because you seem to be using an array of addresses
> while I'm enumerating addresses. I couldn't see a good way of solving the
> problem, I propose a solution later in this e-mail.
> ... I'm happy with limiting the user to three values by default at the moment, (it
> restricts the user but it also simplifies the interface which is already pretty
> complicated). I'm cool with using "Address_Street_1", "Address_Street_2",
> "Address_Street_3", "Address_Street_4",... ,"Address_ZIPPostalCode_1", ...,
> "Address_City_1", ..., "Address_Country_1", ... "Address_State_1". ...

Why not. It is not really a matter whether 3 or 5 addresses are supported. I chose 5 just
per decision:-)

> If you suggest a sequence for fields to be used to contain the type of address
> stored (Business/Home/What the user typed in/Other) then I can put some logic in
> Kontact to check for these fields, and give proper names to the
> corresponding addresses I have read in.  Maybe "Headline_Address_1" ...
>
> Does that make sense? This is a pretty good solution, I think, it means Kontact
> can handle more than 3 addresses, with arbitrary address headlines, if it needs
> to.
>
> There is a subtle i18n problem. It would be beneficial to my GUI if I stored
> the "Address_Headline" in english. This way AB entries in different languages
> could be exchanged and Kontact could work out which address is the Business one
> and which is the Home address. But this would make importing harder in
> kab. You might need something like the following psuedocode in kab

Ahm, I did not mean to fix what is displayed in headline. I simply do not distinguish
between the different addresses to put them in classes (home, business, ...). All of them
mean what the user wants them to. Defaults could be given, but what if somebody does notuse
business addresses at all?

> > > >   /** The title of the person. */
> > > >   QString title;
> > > Is this different from nameprefix? role? Where do I edit this in the kab(1) GUI?
> >
> > 1. How about "Dr. phil."?
> > 2. Nowhere.
> Ah, ok, well title and nameprefix are merged in Kontact. I mean Dr Mr Sanders
> doesn't sound right, at least in English.

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.

> ... > 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.

> > The field "formatted name" is supposed to replace the name composed by the progam,
> > if it does not do it the right way or this special address needs a special
> > ordering. It has nothing to do with storing, but might be used for sorting.
> Sounds like a match

It is used for the user interface, for searching and for displaying the name in one line.

> > > >   /** A possibly name prefix for that person. */
> > > >   QString nameprefix;
> > > Mr/Mrs right?
> >
> > Correct, or "van" (Netherlands", "von" (Germany), ... In this meaning, it is
> > different from a title.
> Hmm, I'm guessing English (the language) is a bit screwed here. Maybe in
> German you would say Dr Mrs Smith?

Herr Dr. Schmidt. It is used this way, I am not responsible for it :-)

> It would be most natural for me to ignore
> the title field and "pollute" the nameprefix field by storing titles (Dr, Prof)
> in it. Alternatively we could make the title/nameprefix fields nonstandard
> fields and avoid overlap.

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.

> ... There is overlap between the concept of keywords and groups. Currently
> Kontact doesn't support keywords, I'm planning on using groups to give the same
> functionality.

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.

> > Do we have a possiblity to implement it the way I wrote above? Seems to be very
> > flexible, in my opinion.
> Implementation isn't the primary issue, the important thing is that we agree on
> common field values. We could do it like I have proposed for addresses. Use the
> fields "Phone_1" .. and "Name_Phone_1" ..., this isn't going to work real
> well when entries in different languages are exchanged, but I can live with
> that.

Hm. Any better proposals? I have no idea, either.

> > This is a kind of agreement, anyway. I will set up a HTML table and post it,
> > unfortunatly I do not have access to a machine permanently connected to the
> > internet.
>
> 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?

> I've talked about nonstandard and standard fields. Lets consider nonstandard
> fields first. Currently Kontact implements a makeshift way of handling these,
> and I am intending to change to this better way:
>
> Nonstandard field values are stored in fields that are prefixed by an identifier
> for the AB GUI (eg "Kab_Rank"), every nonstandard field has a
> corresponding field for storing the name of that field,  (eg "Name_Kab_Rank",
> let's stick with this pattern of prefixing "Name_" and make this a standard).
>
> So an AB entry might contain a field "Kab_Rank" with value "Private", and
> then it must contain a field "Name_Kab_Rank" with value say "Rank". The
> "Name_Kab_Rank" should have the same value for all AB entries made by kab.
>
> (I really need this for Kontact to handle nonstandard fields)
>
> Standard fields are in the global namespace (well would could prefix them by
> say "Standard_") and it is the responsibility of the Addressbook GUIs author
> to define names for these fields when programming their GUI. It is
> recommended that Addressbook GUI authors use the following names [ insert some
> list Mirko is coming up with here :-) ]

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

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?
Greetings,
--Mirko.

--
Denn der  Mensch  liebt und ehrt den  Menschen,  solange er ihn
nicht zu beurteilen vermag, und die Sehnsucht ist ein Erzeugnis
mangelhafter Erkenntnis. (Thomas Mann)

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