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

List:       kde-pim
Subject:    Re: - Project Status report -
From:       Stefan Taferner <taferner () salzburg ! co ! at>
Date:       1999-07-13 8:51:37
[Download RAW message or body]

On Tue, 13 Jul 1999, Don Sanders wrote:
> 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.

Me too. Well, actually my situation is a bit better, as we have a two room
flat. But it's to the north and pretty dark all day long.

> Hearing about a free standing house somewhere in a mountain forest by a
> babbling brook would make a nice change :-)

Our (future) house is on the slope of a valley, surrounded by trees. Quite nice,
as you nearly see anything of the other houses.

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

My problem with all these things is that I do not know Outlook and do not
have access to it. So I can't really say anything about your points. Are there
snapshots of said dialogs available anywhere?  (I know, I can search myself,
but maybe somebody already knows)

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

Ok.

As I don't have time for coding I can only talk of what I would do. Of course it
is finally the decision of those that do the coding.

Kind regards,
Stefan

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