KConfigBase & TODO

[Thomas Braxton]

On Tuesday 13 December 2005 02:57, David Faure wrote:
> Well, there was this other thread where it was said that we should clean up
> that API and use only QVariant.
>  resize( config->readSizeEntry( "Bleh", size() ) );
> would become
>  resize( config->readEntry( "Bleh", size() ).toSize() );
>
> but the KConfigBase API would be very much simpler.
> (And I withdraw my comment about speed, kconfig isn't as much used in
> tight loops as e.g. KIO::UDSEntry is).
>
> Maybe we can do this progressively, with a readVariantEntry, marking the
> existing methods as deprecated, and then when most code has been ported
> to readVariantEntry, we can just s/readEntry/readVariantEntry/ everywhere.
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.
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.
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: text/x-diff
Size: 25096 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051214/487385d1/attachment.diff>