On Wednesday 14 December 2005 18:39, Thomas Braxton wrote:
> we already had most of this with readPropertyEntry, I changed it to readEntry 
> and this is a first pass. What do you think? I couldn't include the diff for 
> kconfigbase.h, it was too large, almost every read*Entry was deprecated and 
> every writeEntry that wasn't for a string, list or QVariant was removed.

Hmm, so readEntry() returns a QString or a QVariant depending on the type
of argument the default value uses? That's a bit surprising, but why not.

Ah, I think (from the test prog, since I don't have your kconfigbase.h), that
you also added a readEntry("keyname",QVariant::Type)? Interesting.

And readEntry("keyname") apparently still returns a QString, that's probably
better for porting.

> The only problems I have are:
> 1) readEntry("keyName", "defaultValue") is ambiguous, the only way I see to 
> disambiguate is at the caller, readEntry("keyName", QString::fromLatin1
> ("defaultValue")), or merge readEntry(QString,QString) with 
> readEntry(QString,QVariant), but I don't think this is the best idea because 
> QString needs to pay attention to localization and QVariant shouldn't.

The third and IMHO better solution would be to add a readEntry(const char*, const char*)
to allow for ascii default values, which are a very common case.

> 2) KConfigSkeleton::ItemLong is ambiguous, do we need more than 2 ItemInt 
> sizes? We could change ItemInt to ItemInt32 and we already have ItemInt64, 
> what do you think?

I don't know much about kconfigxt myself, but I guess you're right, using 32 and 64 is clearer than "long";
Qt itself has moved away from "long" in many places (e.g. QIODevice).

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).