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

List:       kde-pim
Subject:    Re: [Kde-pim] KABC Addresses
From:       Anders Lund <temp_and () tiscali ! dk>
Date:       2002-09-29 22:06:59
[Download RAW message or body]

On Lørdag den 28. september 2002 16:36, Tobias Koenig wrote:
> On Thu, Sep 26, 2002 at 04:54:00PM +0200, Anders Lund wrote:
> > Hi,
>
> Hi Anders,
>
> Yahoo seemed to eat my emails, so here it is one more time :)
>
> > I think it would be a good idear if kabc provided a formatted version of
> > adresses
>
> We had already a discussion about it and came to the conclusion, that we'll
> use templates for it. But we have to wait with it, until the KLanguageCombo
> and KCountryCombo is part of kdelibs. Because in the vcards the country
> name is stored and the l10n stuff of KDE needs a country ISO code (like
> 'de' for Germany) we need this two widgets for translation.
> So we should implement it for KDE3.2.

Fine for me. I'm sorry for repeating allready discussed topics, but I haven't 
read this list for a while. I'd just love to see this in when appropriate.

> > some even in the filed lists:
> >
> > Preferred Address (formatted)
> > Home Address (formatted)
> > Buissness Address (formatted)
>
> No. The Field class is for easy access of string representation of a value.
> It do value->string transformation and vice versa, but
>   1) address parsing is horrible
>   2) for your mentioned needs you can use the formattedAddress() directly
>   3) Cornelius is against it ;)

Well, as far as KAddressBook is concerned, the "select fields" widget used to 
configure views should contain _all_ possible fields, and formatted addresses 
are some of those. If you don't want formatted addresses in there, we just 
have to add those (and possible other "pseudo" fields) to the lists in that 
widget manually, and add the code for getting those strings somewhere too. I 
still think they should go into the lists, as hacking support for them would 
be kinda ugly.

> > "Postbox %Postbox" PURGE_NO_VALUE
> > %Street PURGE_NO_VALUE
> > %Locality", %ZipCode"
> > %Area PURGE_NO_VALUE
> > %CountryCode %Country PURGE_CURRENT_LOCATION
>
> We should use short parameters like %r = region, %s = street.
> Furthermore the template has to be in _one_ line (it is saved in a kconfig
> file)

Ok, my suggestion was partly phrased for ease of understanding. I agree.

> The purge stuff sounds good, but maybe the PURGE_CURRENT_LOCATION
> should be ommited, I can imagine that many users will complain about the
> missing country name ;)

Ok.

> > So my suggestion is, that we add the needed methods/data as soon as
> > possible w/o creating BIC issues:
>
> There's no hurry, adding methods isn't BIC as long as there won't be new
> member variables.
>
> > * a QString as_string() method in the Address object
>
> I would prefer Address::formattedAddress(); like Cornelius mentioned.

Sure:)

> > * members in KABC::Field and KABC::Addressee
>
> No need for it, the string is created on the fly in
> Address::formattedAddress().

Again, the reason for adding them is to make them easily accessible for 
objects wanting to choose some fields.

> > * address formatting information to (KABC local?) l10n database
>
> The templates should be stored in
> $KDEDIR/share/locale/l10n/<cc>/entry.desktop We can access this file with
>   locate( "locale", "l10n/<cc>/entry.desktop" )
> where <cc> is the country ISO code.

That's what I was thinking.

Now, Jost Schenck <jost.schenck@gmx.de> said he was allready working on this, 
so Jost; I hope you read and agree to the conclusions here:)

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