KConfig::addConfigSources is broken

[Thomas Braxton]

On 11/19/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Sunday 18 November 2007, Thomas Braxton wrote:
> > On 11/18/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > > On Sunday 18 November 2007, Thomas Braxton wrote:
> > > > On 11/18/07, Aaron J. Seigo <aseigo at kde.org> wrote:
> > > > > and when Name is set to Bar it will write that value out to
> > > > > d->developerTempFile?
> > > >
> > > > yes :)
> > >
> > > how exactly does it determine the read order?
> >
> > any files set with addConfigSources are treated as "defaults"
> > therefore they are read before the file name passed to the
> > constructor.
>
> huh. well, suffice it to say that this is unexpected behaviour as it doesn't
> match the rest of the kconfig's read/write symmetry pattern. i suppose that's
> why the earlier implementation did it the other way around. *shrug*
>
> if it were up to me i'd suggest that preserving that pattern is more important
> than a new concept of "most specific" where writing is no longer tied to read
> order.
>

if you don't use addConfigSources the filename passed to the
constructor is the last file read, and the file that all non-global
writes go to. so how is this different? what you're suggesting is the
same as openning "kdeglobals" and writing to "appnamerc".

The way it is now opening "appnamerc" with default flags reads files
in this order:

/etc/kde4rc
$KDEDIR/share/config/system.kdeglobals $KDEHOME/share/config/system.kdeglobals
$KDEDIR/share/config/kdeglobals
$KDEHOME/share/config/kdeglobals
$KDEDIR/share/config/appnamerc
$KDEHOME/share/config/appnamerc

Is this wrong? If it is, I seriously misunderstand how the cascading
is supposed to work.

The way I changed addConfigSources was to be *more* symmetrical.
Using the following list of files which would you expect writes to go to?

KConfig config("theFile");
config.addConfigSources(QStringList() << "otherFile1" << "otherFile2"
<< "otherFile3");

Ignoring globals because they are read in the same order before any
files added with addConfigSources.
Before the merge they were read in this order:

theFile
otherFile1 <-- treated as default
otherFile2 <-- treated as default
otherFile3

writes depend on whether you used addConfigSources or not, if you did
they go to "otherFile3" otherwise they go to "theFile".

Now they are read in this order:

otherFile1 <-- treated as default
otherFile2 <-- treated as default
otherFile3 <-- treated as default
theFile

writes go to "theFile" whether or not you used addConfigSources.

With the old way two files are processed as non-defaults if you used
addConfigSources, but only one if you didn't. Some files that are
treated as defaults are read _after_ the local config?!? So which way
is more asymmetrical?

Oh, and the concept of most specific came from comments in
kconfigbackend.cpp, not me. I just used it because I figured that
since it's been in svn for a while now everyone would understand what
I was talking about.