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

List:       kde-pim
Subject:    Re: Addressbook
From:       Rik Hemsley <rik () rikkus ! demon ! co ! uk>
Date:       1999-06-30 13:41:04
[Download RAW message or body]


On 30-Jun-99 Don Sanders wrote:
> Progressing on schedule here. Had a slight change of plans and decided to use
> some MS Outlook style dialogs for creating/modifying an address book entry.
> But
> are sticking with the Outlook Express style dialog for searching/browsing the
> addressbook.

Ok. I'm getting there with the vCard parser.

> I have a couple concerns at this stage:
> 1) I wonder how close can I make it look to MS stuff before they sue me?
> I figured it would be okay as long as I don't copy the icons. Should I rename
> widget labels as well? What else? I was thinking of uploading screenshots
> somewhere and then asking for suggestions for improvements on kde-devel (the
> more feedback the better).

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.

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.

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

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

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

IMO going for a complete vCard 3.0 implementation will be a wise move.
vCard allows custom fields via the 'X-' prefix.

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


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

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.

Cheers,
Rik


--
KDE - Colour outside the lines  : http://www.kde.org
[[without]] - software for KDE  : http://without.netpedia.net

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