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

List:       kde-pim
Subject:    Re: [Kde-pim] KABC Addresses
From:       Tobias Koenig <tokoe82 () yahoo ! de>
Date:       2002-10-01 21:29:12
[Download RAW message or body]

On Mon, Sep 30, 2002 at 11:54:22PM +0200, Anders Lund wrote:
> On Mandag den 30. september 2002 00:44, Tobias Koenig wrote:
Hi Anders,

> > Please no ugly hacks!
> 
> Well I don't intend to. Id rather see _all_ available strings in some list 
> that any user of the KAddressBook class can use.
Ok, than we'll add it to the Field class.

> I don't think you understand the purpose/possibilities of the card view. The 
> idear (and yes, the card view was written by Mike originally on my suggestion 
> and after we discussed it) is that you can display _any_ addressbook data in 
> any order you want to, for any user that you wish, as a "rodolex card" in one 
> scrollable widget.
> 
> There is a screenshot below, which clearly shows that formatted addresses 
> would be nice btw.
It looks really nice, but I've a problem with the code duplication.
We decided that the views give a overview of all available addresses together
with short informations. All formatted or additional informations should
be presented in the details page. That is a clear concept and the card view
tries to break it now. :(

> In the end, the card view will somehow support selecting and copying text, so 
> I can copy for example formatted addresses, account numbers etc directly into 
> where I need it.
IMHO implementing it in details page is better. If somebody likes the icon
view more than the card view he can even so use this feature.

> If you dislike the idear of a flexible view and decides to prevent it, it
> also means that you don't want KAddressBook to be a flexible application
> providing choices for us all,
That's not flexible, thats confusing...
We should present the user a clear concept:
  - views provides overview
  - details page provides more (readable) informations
  - quickedit provides editing facilities
  - ditributionlist/categorymanager provides grouping of contacts

If now every view tries to get a i18n('eierlegendewollmilchsau') (a thing that
tries to provides everything) we get lots of duplicated code => bugs, and
the useability decrease.
Flexibility would be a clear API to extend the 'Views', 'DetailsPage' and
the other main components.

> and I will need once more to think of writing another KABC client -
> something that we all wanted to avoid some time ago when Mike, 
> Andrew and I caused some debate of the KAddressBook user interface.
Features are nice, but they have to be consistent with the rest of the
program. 

> I still think working togeather on making KAddressBook a good and flexible 
> tool is much better, how about you?
I agree, but a reasonable discussion results in a better design. And a
good design provides flexibility and extensibility.

Ciao,
Tobias
-- 
In a world without walls and fences who
needs Windows and Gates???
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]