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

List:       kde-pim
Subject:    Re: - Project Status report -
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-07-13 7:11:16
[Download RAW message or body]

On Tue, 13 Jul 1999, Stefan Taferner wrote:
> On Tue, 13 Jul 1999, Mirko Sucker wrote:
> [...]
> > Stefan Taferner (possibly too busy).
> 
> Unfortunately most of the time, yes. I can give you a report on how my
> house-building is coming along, but this will probably bore most :-)
Well I'm getting sick of living in a one bedroom apartment in a large complex.
Hearing about a free standing house somewhere in a mountain forest by a
babbling brook would make a nice change :-)

> >  How should the addressbook UI work ?
> >  These are our options:
> >  -------
> > 
> >  1. No UI.
> > 
> >  2. A UI that only accepts fields we decide upon. This would have
> >  some tabs for entering common data plus a spreadsheet-like tab to 
> >  edit less common fields. Don is currently working on this.
> > 
> >      3. A UI that is built from a specification and adaptable. This
> > could be built from a KConfig file (Rik has some example code working 
> > that produces a dialog identical to Netscape Messenger's). This might 
> > be more tricky though...
> > 
> > 4. Do not fix the interface at all, simply declare the entry structure.
> > Then you might have different UI's, like a tabular view, kab's "business card" 
> > view, etc.
> 
> How about 3. with the option that the user can select which fields shall be
> shown and which not. This field selection could be some simple checkbox list,
> with every field having the option: "show in list", and "show in details".
> Something like that...
Well I'm voting for 2 and I'll continue voting for 2 with my time and code, for
reasons outlined here http://lists.kde.org/?l=kde-pim&m=93139496601813&w=2

Not that I don't have anything against idea 3 i think it is a fine idea, I just
think that 2 should come first. Note that like all the other components the
address book should (eventually) be an openpart and hence replaceable, there is
no pleasing all the poeple all the time.

I have sent Rik some of my code so that he could have a look at it and he was
even kind enough to put it in the cvs at pim/abui_test alongside his
vcard and ldif code in pim/ldif and pim/vCard. (Actually not all the code is
mine it includes a slightly modified version of Mirko's nice datepicker
dialog). Is there anywhere I can upload screenshots of this so that people can
get some idea of what I have done.

> >      -------
> >      The UI SHOULD be used from every KDE base application to provide
> > consistency.
> > 
> > This is not possibly and not useful. At least not if you fix the UI.
> > Think of the person selector on korganizer, the address selection in kmail, ...
> 
> But still there are IMO many uses for some common dialogs.
> E.g. some sort of quick lookup dialog which contains a list of names and
> returns an addressbook entry.
> 
> > Would you like to see a tabular view all the time? 
I like MS outlooks card view and am thinking of coding a GUI like this, I
think this is a good GUI for the PIM (along with all the other ones Outlook
provides). I think the specific needs of mail clients are different enough to
warrant an additional UI, an incrementally searchable list of addresses. I have
begun coding this and was due to finish in a week and a half but don't think I'm
going to make it in time.    

> Hmm... let's say most of the time. These cases that I don't want to see 
> it (as a programmer), I can make my own specialized dialogs. 
> 
> >Something specialized
> > would be great. The best way is to provide an api to use the common 
> > addressbook, and provide one default database entry interface.
> 
> Yes.  But it has to be a bit more high sophisticated than the current
> kab dialog (speaking of the one of around Kde-1.1).
Well this is what I am trying to help do.

Don.

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