changing the parent of a KConfigGroup

[kde.braxton at gmail.com]

On 1/1/08, Aaron J. Seigo <aseigo at kde.org> wrote:
> hi...
>
> working on plasma stuff today i had the need to move a config group to a new
> location in the file. i either had to descend through the potential group
> hierarchy and copy over the entries one by one and then remove the old
> group,
> which all seemed rather clumsy, or else just change the parent group.
> unfortunately for me (and for dragging plasmoids between containments in
> plasma) there is no way to change the parent group of KConfigGroup.
>
> i figured "how hard could it be?" the attached patch makes this more or less
> work, but i need some cosult with those who have been working on
> KConfigGroup
> stuff lately, in particular with how it relates to the internal entry map
> ...
>
> known limitations:
>
> - you can't move KConfigGroups between KConfigs (as noted in the apidox on
> the
> new method); mostly this is because i'm really unsure what the implications
> of changing the mOwner or sOwner in a KConfigGroup would be and haven't
> researched it thoroughly yet; what i have seen so far tells me it would be a
> bit non-trivial. it would be cool if this limitation was also removed, but
> this patch at least suffices for my simple needs.
>
> - reparent() may not be the best of names; anyone have a better idea?
>
> - KConfigGroup::entryMap, readEntry, etc prior to a sync and re-load is
> almost
> certainly broken with this patch after a reparent() as KConfigGroup just
> passes in the fullName() of the group to the KConfig object to fetch these
> things. it works for me because i'm recreating the config object as needed,
> but will break in situations where the same KConfigGroup is reparented then
> used again. however, i'm not sure how to re-jig the entry map in KConfig as
> there's a fair amount of black magic in there still. this is the point i'm
> hoping someone can pop up and offer some quick guidance on.

this shouldn't break anything, because if you look at fullName() it
recursively calls parent->fullName(mName). So changing parents, it
should return the correct name. The problem seems to be that the way
this is written, it can't work because the _actual_ entries in the
entryMap are not changed to the new name.
> --
> 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
>