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

List:       kde-pim
Subject:    Re: Addressbook
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-07-02 0:20:43
[Download RAW message or body]

On Wed, 30 Jun 1999, Rik Hemsley wrote:
> On 30-Jun-99 Don Sanders wrote:
> You can probably make it pretty close to MS's version. I wouldn't worry. If
> they threaten legal action, we can just change it.
Well that's the plan then.

> I'd ask that you put the code somewhere in CVS so we can play with it. Within
> kab or in somewhere like kdenonbeta/kmail2 would probably suit.
Okay I've only been working on it for a week and a half I have to ftp files
from/to another machine through a modem link every time I want to cvs
update or commit, so I don't do it real often :-(

I don't think kab or kdenonbeta/kmail2 are either suitable places really.
Perhaps it is time for a kdenonbeta/pim? I can e-mail you what I have done so
far if you would like (a weeks worth of work on various dialog layouts in my
spare time).  

> >  2) How can we support groups in the addressbook?
> > As far as I can tell Kab doesn't support groups
> > Teodor worte (correct me if I wrong):
> > "For the card format I would suggest vCard 3.0. Maybe you should have a look
> > at [RFC2426]. It has all the features Kab lacks and could be easily
> > organized into card folders...
> > Anyway, it would be nice to have some CORBA-based directory service with
> > vCard groups stored in recursive folders."
> > 
> > I'm not to sure about this using groups stored in recursive folders stuff,
> > does
> > it allow one person to be in multiple groups? (I think not)
> 
> Well, vCard entities have an optional group name. That means the whole card can
> be within one group. I'm not quite sure how it's supposed to work for the rest
> of the card. I'm storing the groups anyway.
Hmm, only one group? (Not to sure what you mean by "the rest of the card" btw).
 
> > 3) Address ids.
> > What if an application wants to store a list of addresses. It could
> > store the names of people but what if there are multiple people with the
> > same name? Perhaps we need an id for each addressbook entry.
> > (This is an issue even if the addressbook itself wants to maintain a
> > persistent
> > list of entries, say when creating a group of entries). I don't expect that
> > the
> > kab "AddressBook::Entry" class can be serialized (that is saved to disk and
> > reused) something to ask Mirko about.
> 
> A vCard can have an unique identifier. If it doesn't have one, we can create
> one.
I think every vCard should be given one.

> I'll probably implement operators '<<' and '>>' for the vCard components so we
> can stream them. I use this for rmm (the Empath mail parser) and it works well,
> except for the nasty problem of no error checking unless you use exceptions, and
> that Qt's stream operators don't throw exceptions.
Yeah bummer about the whole exception situation. I guess C++ code is
bloated due to using exceptions or ugly due to handling errors without them or
error prone due to not handling erros at all :-(. 

Hopefully compiler technology improves and the cost of using them becomes
more acceptable.

> > 4) I'm not supporting all the vCard fields
> > That would just make the UI bloated (please speak out if you disagree). I'm
> > also not supporting the same ones kab does. I do intend to support custom
> > fields like Outlook does. kab doesn't support custom fields at the moment,
> > but
> > the kabAPI (kdelibs/kab/kabapi.h) looks like it is suitable for supporting
> > custom fields (or keys in kab termininology), because the it has a single
> > method that can be used get any field, that is
> > 
> >   ErrorCode getEntry(AddressBook::Entry& entry, string& key);
> > 
> > Is this a bad idea? Should I just stick with supporting a subset of the vCard
> > fields intially? Does the vCard format allow for custom fields?
> 
> I'd prefer that we could have a switchable addressbook view - from 'simple' to
> 'complete', defaulting to 'simple'. That is usually a Good Thing from the
> user's point of view. Most users will stick with the simple view and ignore the
> 'advanced' version. Once the view is switched, a config entry can be used to
> default back to that type.
I guess I'm working on "complete" now, though most users will only use the first
tab of the addressbook entry editor dialog, which is pretty "simple". 

> IMO going for a complete vCard 3.0 implementation will be a wise move.
> vCard allows custom fields via the 'X-' prefix.
There are going to heaps of custom fields, something like 20 different phone
number fields for instance. Outlook has about 100 fields in total, many of them
are only accessible from a spreadsheet like tab (with name/value columns). That
is what I'm working on now.

> My pattern of work: Implement everything in full and remove the crap later.
> This way you do everything properly anyway, so slimming down is easier.
> 
> > 4) Selecting a preferred addressbook GUI.
> > I'm all for allowing mutiple address book UIs, but this means the user must
> > be
> > given a way of picking the preferred UI. The same issues with preferred
> > colo(u)rs and keyboard accelerators come into play here
> > (ie we should allow for system/user/application specific scopes). 
> 
> I vote for just doing it and worrying about that later. As we've seen, users
> will always ask for enhanced functionality or to be able to tune to personal
> preference. If the thing is usable enough to start with then this won't happen
> for a while.
> 
> With a standard API nothing will stop anyone making a new UI anyway.
> 
> > 5) How should we combine our stuff.
> > I'm thinking of starting with my own very simple address book stub class. And
> > then deriving a new class for the kabapi class. We would have to agree on
> > names
> > for all the vCard fields, (I mean the exact string used as a key to retrieve
> > a
> > particular value).
> 
> They're defined in RFC2426, but not as full names.
> Here's the new types that are in 3.0. I'll dig out the others.
> 
> NAME:        Name        -- ? This is related to the 'SOURCE' somehow
> PROFILE:     Profile
> SOURCE:      Source
> FN:          Full name
> N:           Name        -- ? This is the object's name (person)
> NICKNAME:    Nickname
> PHOTO:       Photo
> BDAY:        Birthday
> ADR:         Address
> LABEL:       Label
> TEL:         Telephone
> EMAIL:       email
> MAILER:      Mailer
> TZ:          Time zone
> GEO:         Geographical location
> TITLE:       Title
> ROLE:        Role
> LOGO:        Logo
> AGENT:       Agent
> ORG:         Organization (with 'z' as it's en_US)
> CATEGORIES:  Categories
> NOTE:        Note
> PRODID:      Product ID
> REV:         Revision
> SORT-STRING  Sort string
> SOUND:       Sound
> UID:         Unique ID
> URL:         URL
> VERSION:     Version
> CLASS:       Class
> KEY:         Key
Okay, here are the outlook fields. I was planning on storing all of these
fields as strings. I'm wondering whether vCard expects certain fields like BDAY
to be stored in a certain format.

Account		
Anniversary	None	
Assistant's Name		
Assistant's Phone		
Attachment	No	
Billing Information		
Birthday	None	
Business Address		
Business Address City		
Business Address Country		
Business Address PO Box		
Business Address Postal Code		
Business Address State		
Business Address Street		
Business Fax		
Business Home Page		
Business Phone		
Business Phone 2		
Callback		
Car Phone		
Categories		
Children		
City		
Company		
Company Main Phone		
Computer Network Name		
Country		
Created	None	
Customer ID		
Department		
E-mail		
E-mail 2		
E-mail 3		
File As		
First Name		
FTP Site		
Full Name		
Gender	Unspecified	
Government ID Number		
Hobbies		
Home Address		
Home Address City		
Home Address Country		
Home Address PO Box		
Home Address Postal Code		
Home Address State		
Home Address Street		
Home Fax		
Home Phone		
Home Phone 2		
Icon		
In Folder	Contacts	
Initials		
ISDN		
Job Title		
Journal	No	
Language		
Last Name		
Location		
Mailing Address		
Manager's Name		
Message Class	IPM.Contact	
Middle Name		
Mileage		
Mobile Phone		
Modified	None	
Nickname		
Office Location		
Organizational ID Number		
Other Address		
Other Address City		
Other Address Country		
Other Address PO Box		
Other Address Postal Code		
Other Address State		
Other Address Street		
Other Fax		
Other Phone		
Outlook Internal Version	0	
Outlook Version		
Pager		
Personal Home Page		
PO Box		
Primary Phone		
Profession		
Radio Phone		
Read	No	
Referred By		
Sensitivity	Normal	
Size	0 B	
Spouse		
State		
Street Address		
Subject		
Suffix		
Telex		
Title		
TTY/TDD Phone		
User Field 1		
User Field 2		
User Field 3		
User Field 4		
Web Page		
ZIP/Postal Code		

> 
> 
> > [...]
> > 7) Standard widgets
> > I ran into problems, I need a combobox widget containing all countries and a
> > validating date edit box. I want a dialog to validate an address, the MS one
> > has US specific crap like STATE and ZIP code I hate that, I guess it has
> > state/province zip/postal code too. Have to work on these.
> 
> Yes, I hate the locale-specific stuff. We shouldn't make ours locale-specific
> like MS does. KDE has much better internationalisation than Windows. We
> shouldn't break that by following their brain-dead ideas.
> 
> We can just have a simple lineedit for the post code and call it something
> different according to locale. Validation would be pointless.
There is a nice little dialog for entering addresses in outlook, it
pops up when leaving the address multiline edit control under certain
circumstances that I have yet to determine (the address validation I was
thinking of) or when they click on a button. I might keep things simple to start
with and only show it if the user explicitly clicks on the push button that
launches it.

> We _can_ validate
> 'phone no.s as there's something in an RFC about that.
> 
> en_US "Zip Code" -> en_UK "Post Code"
>    
> You could possibly use something from kcmlocale for the country combo.
Hmm, I only know of one that lists languages not countries.

> 
> You can use KDatePicker or whatever it's
> called to get dates and probably just make something like a label that displays
> the date and a button to bring up the picker.
Already done. I had to copy some code from the kdebase/kab directory though as
not all of it was in kdelibs

BFN,
Don.

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