--nextPart2375560.nF77Y6TjX8
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 02 December 2005 09:29 am, Oswald Buddenhagen wrote:
> On Fri, Dec 02, 2005 at 01:20:22PM +0000, David Faure wrote:
> > SVN commit 484988 by dfaure:
> >
> > Ingo's wish is my command: adding writeEntry(key,QList<QByteArray>)
> > and readByteArrayListEntry.
>
> i think inflating the KConfigBase api with increasingly specialized and
> weird read*Entry and writeEntry methods goes into the wrong direction.
>
> the imo right approach is having to/fromString methods in the classes
> themselves. the remaining classes can have marshallers in KConfigBase
> or (preferably?) some other class - that would particularly apply to
> QList<>.
> in any case it is essential to have the un-/marshallers available
> separately, so one can nest them freely. i missed such a possibility
> repeatedly.
>
> the {read,write}Entry core should be template-based, with explicit
> instanciations for the common cases (PODs, string lists and various
> other Q types - well, the sane part of the current api).
Really I think the QSettings direction is way more useful to me as a=20
developer.  With the current KConfig api I have to remember a million=20
methods, and if they even exist.  With the QSettings api, i just have to=20
remember that the value is a valid QVariant. =20

Just my 2c though.

Cheers
 -ian reinhart geiser

--nextPart2375560.nF77Y6TjX8
Content-Type: application/pgp-signature

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

iD8DBQBDkHpcPy62TRm8dvgRAuNIAJ9wSJnsjbWzznCmQYkvY4TMOMS/1QCgrOKq
cDVyUscZ0yG4OC+VnlRE8z4=
=jIBo
-----END PGP SIGNATURE-----

--nextPart2375560.nF77Y6TjX8--