[PATCH] KCoreConfigSkeleton

[Aaron J. Seigo]

On Saturday 24 November 2007, Oswald Buddenhagen wrote:
> On Sat, Nov 24, 2007 at 09:08:27AM -0700, Aaron J. Seigo wrote:
> > there's an additional problem now that we have nested groups as well:
> > config objects may not start at the root of the file.  right now
> > KConfigSkeleton assumes it owns the entire file and there is no way to
> > make it start from a given sub-group that i can find since it takes a
> > KSharedConfig::Ptr in the constructors ...
> >
> > then there are methods like writeConfig(KConfig * config) ...
> > shouldn't those take a KConfigBase* isntead? that would at least make
> > it possible to extend to allow applying a KConfigSkeleton to a config
> > object starting at a non-root group.
>
> hmm, that's an interesting topic.
> the nested groups are no problem as such - the code can be extended to
> deal with it.
> the actual issue you have is that the whole stuff assumes a static
> structure from the root down and defines the file to be the root, while
> you want to pass some subsection as the root.

exactly...

> i don't see a fundamental issue with passing KConfigBase instead of
> KConfig. however, this needs to be checked for side effects. i think at
> least the kcfg file needs to mark those groups as dynamic, either
> entirely dynamic or with some pattern the group name should comply with.
> otherwise, for example, the legendary kcfgedit would try to put it in
> the root of a file.

+1

> note that instead of changing the "supply type" now, we can later add
> KConfigGroup overloads in a SC & BC way, so this isn't a "must do now"

agreed ... 

> thing as far as the libs go. not that's i'm opposed to going into this
> further - and after all you have an immediate need - i just thought i'd

yep, i do =/ what i've one right now is change the public API of our ConfigXml 
class to take a KConfigBase* instead of a KSharedConfig::Ptr. it still 
doesn't do what we need it to internally, but the API is now ready in 
libplasma; next would be getting KConfigSkeleton working.

the timing is really funny because i only realized the ConfigXml breakage 
yesterday and then your email came today ;)

> mention it, as i expected you to be the one to impale me for making the
> original proposal in the first place. ;)

i'm torn, indeed. i really don't like the timing of the kconfig stuff, but 
we've come this far it'd be nice to not ship with something half working.

> > i also noted that there are virtual methods that are inline in the
> > header. shouldn't those go into the implementation?
>
> that's because its templated stuff, i think. i haven't touched this, so
> i don't know.

ah.. yeah, it is from one of the templated classes. unfortunate.

-- 
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/20071124/e3034beb/attachment.sig>