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

List:       kde-promo
Subject:    Re: [kde-promo] In need for name of a project
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2007-01-26 18:19:56
Message-ID: 200701261119.57206.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 26 January 2007 5:06, Friedrich W. H. Kossebau wrote:
> Short target kdepimlibs, long target kdelibs. Why? Because there is a list
> of users and groups, that I want to integrate, the users and groups of the
> computer system. So developers of programs like a file manager,

kdebase already depends on kdepimlibs, so that's not a big deal. given your 
ambition here, though, it would probably make sense to meld it with the other 
names we have:

solid, phonon, decibel, sonnet .. 

if it was pim only, i'd look for harmonization with akonadi, but it seems you 
want broader scope? hm.. actually, that's another interesting question: what 
would the relationship with akonadi be? if it does end up having some sort of 
coordination with akonadi, perhaps it makes sense to follow the african 
mythology theme to keep some sort of theme going there.

> > will there also be an application provided that needs a name as well?
> > e.g. the next evolution of kaddressbook?
>
> Yes, there need to be some programs/modules that allow the editing/browsing
> of the data. There would be a standalone program, an ioslave(?)/kpart
> combination or something else.

ok.. so there would be both a framework name as well as an application name. 
the appname should, imho, be simple and descriptive of the purpose. 
frameworks can get 'funky' names but apps should remain identifiable to users 
if at all possible... 

> > also, is this going to be compatible with less interesting
> > implementations that use only vCard (e.g. the rest of the world), or is
> > it its own little world? (in the latter case the name probably needs to
> > stay away from certain words)
>
> I guess being vCard compatible is needed very much. The experimental code I
> did so far is build on simply using the KABC interface, so it might be
> possible to express the model in vcard terms. At least I am optimistic.
> Sure, there will be data loss when exporting to the vCard-only world. And

yes, i would expect this to be a largely one-way operation, with export 
resulting in loss of information. but since this is already in the pipe, we 
don't have to avoid something that might imply contacts.

would this framework possibly replace KABC (possibly consuming KABC as an 
internal component for vcard reading?) as the preferred system for contacts 
storage and retrieval?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

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



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