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

List:       kde-core-devel
Subject:    Re: KConfigBase & TODO
From:       Thomas Braxton <brax108 () cox ! net>
Date:       2005-12-20 20:03:12
Message-ID: 200512201403.12597.brax108 () cox ! net
[Download RAW message or body]

On Tuesday 20 December 2005 13:08, David Faure wrote:
> On Tuesday 20 December 2005 19:29, Thomas Braxton wrote:
> > On Sunday 18 December 2005 17:13, Thomas Braxton wrote:
> > > You can download  a new diff @
> > > http://members.cox.net/brax108/KConfig/diff
> >
> > Has anyone had a look at this? I haven't seen any comments, can I commit?
> > It's kind of a big diff, I don't want to commit without feedback.
>
> To me it looks fine.
> An obvious question is: does the rest of kdelibs compile with this change?
> (if not, please port it so that it does).

testing now

> This kind of change in the test program isn't necessary anymore, right?
> -  QCOMPARE( sc2.readEntry( "stringEntry2", "bla" ), QString( "bla" ) );
> +  QCOMPARE( sc2.readEntry( "stringEntry2", QString("bla") ), QString(
> "bla" ) );

Technically no, but wanted to ensure that readEntry(const char*, QString) 
still returns the right thing.

> Speaking about the test program it still uses 
> readByteArrayListEntry, it's probably fine to test the deprecated methods
> while they are there, but it would be good to add a test for the QVariant
> variant :)

The read*ListEntry functions are not changed over yet. The reason 
readEntry(QString, QStringList) works is because there is a 
QVariant(QStringList) conversion, this won't work for others because the only 
other type of list QVariant understands is QList<QVariant>, so any other type 
of list would have to be converted.

> Please don't forget to add an entry to KDE4PORTING.html too.
will do
[prev in list] [next in list] [prev in thread] [next in thread]