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

List:       kde-core-devel
Subject:    Re: KConfigBase & TODO
From:       David Faure <faure () kde ! org>
Date:       2005-12-18 11:43:02
Message-ID: 200512181243.02870.faure () kde ! org
[Download RAW message or body]

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


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