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

List:       kde-pim
Subject:    Re: [Kde-pim] kabc question
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-07-05 9:10:54
[Download RAW message or body]

On Friday 05 July 2002 00:32, Reinhold Kainhofer wrote:
>
> 1) Can I safely sync the palm address data with
> KABC::Addressee::address(0), so I don't have to use a "Address is home
> address" vs. "Address is work address" option to distinguish? Or does this
> create problems somewhere, and I have to set KABC::Address::Work or
> KABC::Address::Home?
>
> As far as I saw, KAddressbook only displays the address if it has
> KABC::Address::Home or KABC::Address::Work set. Any other problems, so that
> I can't go the easy way for the sync?

In principle you can use whatever flags you like. But to make the snycing 
useful you need a program which is able to show the address. I think we 
should adapt KAddressBook to also show addresses with other types than home 
and work.

> 2) Also, the KABC::Addressee::address function checks for exact matches of
> mType, which often is not what one would expect. E.g. I have only one
> Address in an entry, but that Address is marked as a preferred home address
> (Home|Pref). Of course, I'd expect to get that address, too, if I only call
> Addressee::address(KABC::Address::Home)...
>
> I think that if an exact match of the type exists, the corresponding entry
> should be returned, otherwise if the requested bits are a subset of an
> address (e.g. address(Home), while there is only an item with Home|Pref)
> that one should be returned instead of an empty address. If the developer
> really needs an exact match, (s)he can still check if the mType is exact or
> just approximate.

Makes sense, but the address() call would then have to return a list of 
addresses, as there can be multiple addresses having the same flag set. In 
principle there could even be multiple addresses with exactly the same type, 
although libkabc currently doesn't support that. 

> I'm aware that the algorithm for this might not be trivial in every case,
> but I think somethink like an implicit tree hierarchy of the
> bit-combinations might achieve this.

Wouldn't it be sufficient to perform a binary and on the type and the given 
parameter and return all addresses where this operation results in true?

> 3) Another "feature" I found with kabc:
> KABC::Addressee::address() and phoneNumber(..) can only return one address
> with that type, however, one can have more than one address and phone
> number of a given type (I initially thought that there can only be one of a
> certain type, but then I found that with every sync another copy of the
> address was added...). If this is intended (I suppose it is), then the
> phoneNumbers() and addresses() functions should be extended with an
> optional type to return a list of only addresses/phonenumbers of a given
> type so that one doesn't have to get the whole list and check the type of
> each entry manually.
>
> At least, the docu of Addressee::phoneNumber should read "Return first
> phone number, which...", and the same with Addressee::address().

Hm, I think we should either fix the code to not allow multiple addresses and 
phone numbers with the same type of make the functions return lists. Ok, we 
can't do that because of binary compatibility and it might be better anyway 
to rename the functions to phoneNumbers() and addresses(). So the best way 
seems to be to add functions "Address::List addresses( int type )" and 
"PhoneNumber::List phoneNumbers( int type )" and change the docs as you have 
suggested.

-- 
Cornelius Schumacher <schumacher.kde.org>

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