[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-07-02 0:44:42
[Download RAW message or body]


On 02-Jul-99 Don Sanders wrote:
> 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).  

Ok. I'll make a pim module and put my vCard parser and your dialog work in
there.

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

Each 'Content-line' can have a group.
This means you could have something like this:
group1.BEGIN:VCARD
group2.FN:Rik Hemsley
group3.VERSION:3.0

I'm not quite sure what this achieves.

From the rfc:

 Profile special notes: The vCard object MUST contain the FN, N and
   VERSION types. The type-grouping feature of [MIME-DIR] is supported
   by this profile to group related vCard properties about a directory
   entry. For example, vCard properties describing WORK or HOME related
   characteristics can be grouped with a unique group label.

So perhaps you'd do something like this:

home.ADR;TYPE=home,postal:;;My address...

But this just makes the 'home.' group redundant as it's specified in the
parameters. Maybe you're supposed to use it for faster indexing or something.
Strange stuff.

You're not going to have a different birthday at work, but I can perhaps see
how you'd want a photo of yourself at your desk at work in 'work,' and one with
you pissed on the floor at home in 'home.'. Hmm.

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

Ok, that's easy and was what I was intending doing.

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

I'm not quite sure how to progress here.
From the rfc:
   CHAR         = %x01-7F
        ; Any C0 Controls and Basic Latin, excluding NULL from
        ; Code Charts, pages 7-6 through 7-9 in [UNICODE]

I presume this means single-byte unicode, though I don't know enough about
Unicode to be sure. If it is, then we can just save to a text file as 8-bit.

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

That's fine. So long aren't presented with the option to fill in their
geographical location via link-up to a GPS on the first screen ;)

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

This is how the rfc specifies tel-type:

tel-type     = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG"
                / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN"
                / "VIDEO" / "PCS" / iana-token / x-name

So you can have something like this:
TEL;TYPE=work,voice,msg,pref:3972109471;TYPE=home,isdn:39249444;TYPE=X-AnotherTy
pe,modem:30482882

This just means that vCard does it in a different way to Outlook.

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

Yes, many of the vCard values have their own formats. Some of them are defined
in rfc2425 ('A MIME Content-Type for Directory Information'). Others are
defined within 2426 (the vCard rfc), such as utc-offset-value:

   utc-offset-value = ("+" / "-") time-hour ":" time-minute
   time-hour    = 2DIGIT                ;00-23
   time-minute  = 2DIGIT                ;00-59

Storing fields as strings just loses us the ability to have them automagically
parsed into usable objects and therefore searched/sorted 'correctly'.

The vCard parser's job is to create real live objects for types it knows about.
This will mean you can do this:

using VCard; // Doesn't work in my egcs, but I just use VCARD:: instead.

VCard v("BEGIN:VCARD\nBDAY:1996-04-15\nEND:VCARD");

if (v.has(EntityBirthday)) {
  DateValue * d(v.contentLine(EntityBirthday).value());
  cout << "Date is " << d->day() << "/" << d->month() << d->year() << endl;
}

> Account
> Anniversary   None
> Assistant's Name           
> Assistant's Phone

I think we can just put what we feel is useful in and allow for extensions via
the spreadsheet-style widget.

Perhaps this is a job for the group thing ?

assistant.TEL:02838 32844

That might just be it.

I'd really like to see an adaptable GUI, but I don't think anyone wants to do
that. Perhaps when I've finished my current 3 projects ;)

I really think it could work though. We know the types of each field and can
ask for them when an extension type is created.

For example:

QString fullTypeName = "Telephone";
QString shortTypeName = fullToShort(fullTypeName);
EntityType entityType = ParamNameToEntityType(name_);
ValueType valueType = EntityTypeToValueType(entityType);

switch (valueType) {

        case ValueAddress:
                // Create an address selection widget
        case ValueTel:
                // Create a telephone number editing widget
        case ValueText:
                // Create a Q(Multi)LineEdit
}

This way we can do something clever like simply have a KConfig file:

(Note that there are two items for each - 'Nickname' is the actual field name,
while 'Nick' is the displayed text)

[General]
Pages=Personal,Dates,Contact
[Personal]
Fields=Full Name, Full Name, Nickname, Nick
[Dates]
Fields=Anniversary,Anniversary,Birthday,Date of Birth,X-Last-Meeting,Last
Meeting
[Contact]
Fields=Email,Email address,Address,Work address,Address,Home address

Something like this would then be appropriate:

KConfig * c(KGlobal::config());
c->setGroup("General");
QStringList l;
c->readListEntry("Pages", l);
QStringList::ConstIterator it(l.begin());

for (; it != l.end(); ++it) {

        c->setGroup(*it);
        QStringList fields;
        c->readListEntry("Fields", fields);

        QStringList::ConstIterator it2(fields.begin());
        
        for (; it2 != fields.end(); ++it) {

             QString fieldName = *it2;
             QString displayName = *(++it2);
             
             createWidget(fieldName, displayName);   
        }
}

'createWidget(...)' would then use the code above for getting the entity type.
This would do something like creating a label to the left and then the
appropriate widget for the entity type to the right.

Is this too much magic ? I think if I can write the code to do it here off the
top of my head it must be somewhere near possible ;)

I think you should see that with this kind of system we get to choose exactly
what goes on the dialogs and where.

The code for getting entity types etc is already in my vCard parser.

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

Ok. That's got to be better. I can't imagine a bigger headache than trying to
validate addresses written in Cantonese.

>> You could possibly use something from kcmlocale for the country combo.
> Hmm, I only know of one that lists languages not countries.

I was just thinking of changing 'English - UK (en_UK)' to 'United Kingdom' etc
as a basis, seeing as there's lots of flags and a ready made widget :)

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

Ok.

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]