KConfig::addConfigSources is broken

[Aaron J. Seigo]

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:
> > > That's what I was saying, in the code he posted he expects writing to
> > > be to a file he added with addConfigSources not to the file he opened.
> > > imho you should be opening the file you expect to write to, not one of
> > > it's defaults which is what he did.
> >
> > the point that is being missed here is that read/write is:
> >
> > a) no longer symmetrical
>
> I think you're mistaken, he wants to write to a more specific file by
> opening a less specific file. that's like opening
> "$KDEDIR/share/config/kdeglobals" explicitly, then expecting KConfig
> to know he wants to write to "$KDEHOME/share/config/kdeglobals".
> KConfig doesn't handle that case either, never did afics.

no, it's like opening kdeglobals and having it write to 
$KDEDIR/share/config/kdeglobals even though its reading from 
$KDEHOME/share/config/kdeglobals.

this is because when you call addConfigSources it apparently cascades the 
reads, but not the writes. that's the symmetry that's broken.

> > b) this is a (unnecessary) behaviour change from past KConfig
> >
> > (a) is true because reading prefers developerTempFile but writing prefers
> > projectTempFile. this is an added complexity that makes no real sense
> > compared to how everything else in kconfig works. (from a user of
> > kconfig's perspective, anyways).
> >
> > because of this broken symmetry, how is Andreas supposed to accomplish
> > what he wants: a kconfig file used as a template for reads, with a custom
> > file to store changes in?
>
> the way I posted earlier.

the way you posted earlier doesn't work. because now instead of having a write 
problem, he has a read problem. read his issue very carefully and you will 
see this. this is why symmetry between read/write must be kept!

> > (b) this is not how it worked in KConfig from KDE3. this will introduce
> > subtle and unnexpected bugs into software. in fact, as you can see, this
> > has already happened.
>
> this function iirc wasn't in kde3, it was added in r563544, so how
> does this break kde3 software?

it breaks with the concept of read/write symmetry that is part of cascading 
configurations.

it also didn't apparently work that way before the merge.

> > so please change this back to how it was. =)
>
> ok. so if addConfigSources is called the last file name in the list
> becomes the most specific file?

i'm really not sure what you're meaning by "specific", but since it seems to 
have led to an odd situation in the current code, i'm going to use slightly 
different terms that are hopefully a bit clearer:

if addConfigSources is called, the last file should be the one written to 
since it is the last one read to.

alternatively, if addConfigSources is called, the file name passed into the 
constructor should be the one that is read from last since it is the one that 
is written to last.

either way, the symmetry between read/write needs to be kept.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071118/4993c195/attachment.sig>