On Sunday 18 December 2005 05:43, David Faure wrote:
> 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.

don't need it, QVariant has a constructor for QVariant::Type, so we get an 
implicit conversion.

You can download  a new diff @
http://members.cox.net/brax108/KConfig/diff

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

I didn't think of that, that would probably do it for most uses of 
readEntry(QString,QString).

> > 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).
I'll commit this.