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

List:       kde-pim
Subject:    Re: [Kde-pim] Kaddressbook: Organizations and people
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () kossebau ! de>
Date:       2006-07-31 12:44:27
Message-ID: 200607311444.28289.Friedrich.W.H () kossebau ! de
[Download RAW message or body]

Hi Lorenzo,

Am Montag, 31. Juli 2006 13:43, schrieb Lorenzo E. Danielsson:
[idea for multiple categories of contacts, like organizations and people]
> So first, the question, what obvious thing am I missing? Why is it not a
> good idea to have organizations as a "separate entity" from people? If
> there are specific reasons for why all contacts are treated equal (more or
> less as people) then I'd really like to know (out of curiosity), because
> this has been itching for some time now.

I may be due to the complexity involved ;) And not too many who were able to 
scratch this itch of them. :P

I am not the maintainer of KAddressbook, also yet not involved with Akonadi. 
But I am playing since a while with the concept of 
contacts/users/roles/entities, thinking about how to do the modelling and 
usage interfaces and such things (see for a working experiment the contacts 
framework I keep blogging about :) ), for a later inclusion with KDE's 
programs.

Yes, I agree with you, such a thing would be very useful for power users 
(organisations also things like households, etc). Next to things like linking 
people with their roles (mother of, brother of, employee of, secretary of, 
etc). I am already trying to integrate these concepts into an proposal of 
mine hopefully ready for Akademy and discussion with everyone. Currently I am 
out of time, though :(

As said above, the twist will surely be how to implement it and how to do the 
user interface(s), without stopping simple users. :/

> If, on the other hand, somebody else agrees that it would be useful to be
> able to create "contacts" that are either "organizations" or "people", what
> is the best next step? File a feature request? Be patient? Get my hands
> dirty? All of the above?

I think all of the above, in the sequence you give :) I guess you already have 
thought more about it? So please add them to your feature request, perhaps by 
also starting a new page on wiki.kde.org and linking to it from your request 
on bugs.kde.org. I personally favour collecting use cases in the beginning, 
so tell why and how this feature is needed. It helps to design solutions and 
caring for as much aspects as possible.

Regards
Friedrich
_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://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]