--===============0241420037== Content-Type: multipart/alternative; boundary="----=_Part_33512_15918144.1169754909528" ------=_Part_33512_15918144.1169754909528 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Crowd Control. On 1/25/07, Friedrich W. H. Kossebau wrote: > > Hi, > > I need your help. > > I am working on something that is aimed to be in KDE 4, and in a primitive > variant will already be part of the KDE 3.5.7 PIM release, if things go > right. But I lack a matching name, one that is descriptive and doesn't > narrow > what people expect from it. The last point is most important, so far I had > problems to explain the stuff to people, because they are usually blinded > from things existing and I know nothing I could easily refer to as > template > (also my english and explaining abilities are bad ;). > > The project is about modelling persons and groups/projects. Or "about the > things you know about people and their extended virtual personas.", like > de > Groot has put it. Think KABC on steroids. Or better, don't think it, > because > it has a new approach. > > Unlike KABC nothing is hardcoded, but everything is controlled by plugins. > Currently, if you want to add proper support for someone's > WebGalleryOfTheDay > account, or a second homepage, you will find that not really supported. > The project solves this by treating a person/group as a list of items of a > given property type. Available types are controlled by the installed > plugins, > which (shall) deliver viewers and editors (cmp. widgets in QtDesigner). So > there will be e.g. an email address type plugin, and one for computer > account > types, web pages types, WebGalleryOfTheDay account types, whatever someone > needs and implements. > Thus the data that is collected about one is not only used to contact her, > or > are only addresses. There could be any metadata one would like to have. > Like > notes, emotional attributes, links to other persons (sister, assistent, > whatever). > Because of this I don't like names like Contacts or Addressbook, as they > limit > everyone's idea of what is possible. > > And there won't be only persons, but also groups, that is collections of > persons. And also groups of groups (and persons). Groups could have own > properties, like a plain person has. > Persons could have different identities and belong only with an identity > to a > group. > > Example, modelling your view on the persons and groups of the KDE project: > * KDE - group, with a homepage, a news feed, a anniversary, etc. > * KDE developers - group, with several mailinglists, chat channels, > homepage, > subgroup of KDE > * KDE translators - group, > * Joe Developer - identities developer, work, private, with each a > homepage, > chat name, email address, member of group KDE > developers as developer and group Friends as private > *... > > But the project does not end here: > One does not only want to display and edit the properties of persons and > groups, but do something on them. This is again solved in a generic way, > by > three kind of service types per property type. For this please see > http://www.kde-apps.org/content/show.php?content=42120 > as this is already (evolving) working code, some that should get into > KDEPIM > for 3.5.7 > > The project should also feature some basic widgets, which should make life > easier for developers using the framework. So programs like KMail, Kopete, > Konqueror (file owner), multiuser games, all those where there are things > representing persons/groups, could make use of it. > Cmp. the person icon in the upper right of an email from a person you have > in > the addressbook. Right now the support to chat or email is hardcoded. > With this project's framework all KMail developers should have to do is > something like > Person *p = Framework::getPersonBySystem( "email", emailaddress ); > PersonLabel *pl = Framework::createLabel( p ); > or such, and get all the rest for free, that is display of status and > available actions in the context menu. > > So we would move towards an also persons and groups centric desktop, with > some > kind of proxy objects for them. One e.g. no longer goes for the mail > management program and selects the folder with the emails of your friend, > but > instead go to your friend('s proxy symbol) and select his emails. As an > option of course. Traditional desktop approaches for those of the last > century will surely be kept ;) > > I guess most of you haven't used the Contacts applet before, right? > See http://www.kde-apps.org/content/show.php?content=34479 > If you have you might get the idea what I envision. There you can have > something like the list of chat partners in Kopete, but enriched with all > possible and impossible status and action services, depending on the > properties. Others are behind popupmenus, so I can use it like the > bookmark > menu to reach someone's homepage, except that I go by persons, not > resourcetype like with the list in Konqueror. Same with the blog. Right > now > the support is broken, but in an earlier version one could select and go > to > the latest blog entries by the same menu. And see in the proxy object > display > if there are new unread blog entries. Like one can see now if there are > new > emails. Or if someone is logged onto my computer. Etc. pp. There are so > many > use cases if you start thinking about it. And it only depends on the > installed plugins. > > I hope you got a first idea what this project is about. If not, please > ask. > > So, what do you think would be a good name for this? I once tried > "Organs", > because the project models the organization of the persons and groups > around > one. But I guess that won't work. Nonenglish terms are welcome, too, if > they > are still meaningfull and connected. > > Friedrich > > _______________________________________________ > This message is from the kde-promo mailing list. > > Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set > digest on or temporarily stop your subscription. > ------=_Part_33512_15918144.1169754909528 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Crowd Control.

On 1/25/07, Friedrich W. H. Kossebau <kossebau@kde.org> wrote:
Hi,

I need your help.

I am working on something that is aimed to be in KDE 4, and in a primitive
variant will already be part of the KDE 3.5.7 PIM release, if things go
right. But I lack a matching name, one that is descriptive and doesn't narrow
what people expect from it. The last point is most important, so far I had
problems to explain the stuff to people, because they are usually blinded
from things existing and I know nothing I could easily refer to as template
(also my english and explaining abilities are bad ;).

The project is about modelling persons and groups/projects. Or "about the
things you know about people and their extended virtual personas.", like de
Groot has put it. Think KABC on steroids. Or better, don't think it, because
it has a new approach.

Unlike KABC nothing is hardcoded, but everything is controlled by plugins.
Currently, if you want to add proper support for someone's WebGalleryOfTheDay
account, or a second homepage, you will find that not really supported.
The project solves this by treating a person/group as a list of items of a
given property type. Available types are controlled by the installed plugins,
which (shall) deliver viewers and editors (cmp. widgets in QtDesigner). So
there will be e.g. an email address type plugin, and one for computer account
types, web pages types, WebGalleryOfTheDay account types, whatever someone
needs and implements.
Thus the data that is collected about one is not only used to contact her, or
are only addresses. There could be any metadata one would like to have. Like
notes, emotional attributes, links to other persons (sister, assistent,
whatever).
Because of this I don't like names like Contacts or Addressbook, as they limit
everyone's idea of what is possible.

And there won't be only persons, but also groups, that is collections of
persons. And also groups of groups (and persons). Groups could have own
properties, like a plain person has.
Persons could have different identities and belong only with an identity to a
group.

Example, modelling your view on the persons and groups of the KDE project:
* KDE - group, with a homepage, a news feed, a anniversary, etc.
* KDE developers - group, with several mailinglists, chat channels, homepage,
subgroup of KDE
* KDE translators - group, <same as above>
* Joe Developer - identities developer, work, private, with each a homepage,
chat name, email address, member of group KDE
developers as developer and group Friends as private
*...

But the project does not end here:
One does not only want to display and edit the properties of persons and
groups, but do something on them. This is again solved in a generic way, by
three kind of service types per property type. For this please see
http://www.kde-apps.org/content/show.php?content=42120
as this is already (evolving) working code, some that should get into KDEPIM
for 3.5.7

The project should also feature some basic widgets, which should make life
easier for developers using the framework. So programs like KMail, Kopete,
Konqueror (file owner), multiuser games, all those where there are things
representing persons/groups, could make use of it.
Cmp. the person icon in the upper right of an email from a person you have in
the addressbook. Right now the support to chat or email is hardcoded.
With this project's framework all KMail developers should have to do is
something like
        Person *p = Framework::getPersonBySystem( "email", emailaddress );
        PersonLabel *pl = Framework::createLabel( p );
or such, and get all the rest for free, that is display of status and
available actions in the context menu.

So we would move towards an also persons and groups centric desktop, with some
kind of proxy objects for them. One e.g. no longer goes for the mail
management program and selects the folder with the emails of your friend, but
instead go to your friend('s proxy symbol) and select his emails. As an
option of course. Traditional desktop approaches for those of the last
century will surely be kept ;)

I guess most of you haven't used the Contacts applet before, right?
See http://www.kde-apps.org/content/show.php?content=34479
If you have you might get the idea what I envision. There you can have
something like the list of chat partners in Kopete, but enriched with all
possible and impossible status and action services, depending on the
properties. Others are behind popupmenus, so I can use it like the bookmark
menu to reach someone's homepage, except that I go by persons, not
resourcetype like with the list in Konqueror. Same with the blog. Right now
the support is broken, but in an earlier version one could select and go to
the latest blog entries by the same menu. And see in the proxy object display
if there are new unread blog entries. Like one can see now if there are new
emails. Or if someone is logged onto my computer. Etc. pp. There are so many
use cases if you start thinking about it. And it only depends on the
installed plugins.

I hope you got a first idea what this project is about. If not, please ask.

So, what do you think would be a good name for this? I once tried "Organs",
because the project models the organization of the persons and groups around
one. But I guess that won't work. Nonenglish terms are welcome, too, if they
are still meaningfull and connected.

Friedrich

_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription.

------=_Part_33512_15918144.1169754909528-- --===============0241420037== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. --===============0241420037==--