--===============1643451553==
Content-Type: multipart/signed;
  boundary="nextPart3327342.eJz12e60sI";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3327342.eJz12e60sI
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 26 January 2007 12:32, Friedrich W. H. Kossebau wrote:
> > 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 purpos=
e.
> > frameworks can get 'funky' names but apps should remain identifiable to
> > users if at all possible...
>
> Don't we have the generic name for this? ;)

generic names are helpful but don't solve the problem. to disambiguate=20
between "address books" people use the name of the application. if you look=
=20
at some platforms, the names are pretty straightforward and obvious (at lea=
st=20
once you hear what they do; windows and mac os both fall into this category=
)=20
while on others they don't (e.g. gnome and to a lesser extent kde). i get a=
=20
lot of feedback from people that they really don't like the overly abstract=
=20
application names because it makes it too hard to remember what is what or =
to=20
communicate effectively with others.

kimdaba used to be a favourite example of mine, but they fixed that: now it=
's=20
kphotoalbum. much better.

look at gnomemeeting which is now ekiga for an example in the reverse=20
direction.

> It would be something like "Persons and Groups/Projects manager". Or
> "People manager". Or?

that would be a good generic name, but the application should also have a=20
clear actual name imho.

the framework can be funkier due to the audience.

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

i was concerned that if this framework was not going to be interoperable wi=
th=20
simple vCard clients, that the name should not imply "contact information"=
=20
too strongly since that could well mislesad people. evidently that's not an=
=20
issue so we're open to more variety in names.

> > 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?
>
> More or less, yes.

ah, definitive answers ;)

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

=46ull time KDE developer sponsored by Trolltech (http://www.trolltech.com)

--nextPart3327342.eJz12e60sI
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBFum8D1rcusafx20MRAvhuAJ90UsSLUAot+wqlb4h1oguONf5x7gCfQ5Ih
VctXZJHsoDZYIf67LM1JvlY=
=/2P6
-----END PGP SIGNATURE-----

--nextPart3327342.eJz12e60sI--

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