Review Request: Add ability to define which KConfigBackEnd to use with KSharedConfig

[Thomas Braxton]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4220/#review5980
-----------------------------------------------------------


The functionality you are adding is already there using undocumented behavior of KConfig. You should get an anonymous in-memory config if you call KSharedConfig::openConfig("",KConfig::SimpleConfig). I suck for not documenting this behavior :(

- Thomas


On 2010-06-03 22:44:47, Aaron Seigo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4220/
> -----------------------------------------------------------
> 
> (Updated 2010-06-03 22:44:47)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> Right now KSharedConfig assumes it is loading a file in the standard KDE hierarchy (e.g. in KStandardDirs and with the INI backend (or whatever is eventually configurable for that)). This is usually just fine, and KConfig allows opening a resource with a specific backend. But we have classes such as KCoreConfigSkeleton which require a KSharedConfigPtr. This patch alters KSharedConfig to allow requesting a given file with a given backend. 
> 
> The use case that prompted this is in Plasma::Service where KConfigSkeleton is used to load and manage the description of a service's operations. KConfigGroup is used to store parameters associated with the service. This means we require a KSharedConfigPtr for this. Which means that up until now, we have been using a KTemporaryFile to do this. When there are lots of services flying around (or someone leaks them) this leads to exhausting the file handles available, not to mention it means a lot of filesystem interaction that is completely unecessary. We just need an in-memory representation behind KConfig (which is something we did in KDE 3 as well, btw :).
> 
> This patch makes that possible.
> 
> KConfigSharedPtr's loaded with different backends are kept away from each other by keeping a separate QList for each backend that gets used. The backend type in use is not kept around in KConfig (not should it really, since it may have multiple backends loaded (not implemented, *still*, but that's the idea)) so the bookkeeping must be done here.
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdelibs/kdecore/config/ksharedconfig.h 1130620 
>   /trunk/KDE/kdelibs/kdecore/config/ksharedconfig.cpp 1130620 
> 
> Diff: http://reviewboard.kde.org/r/4220/diff
> 
> 
> Testing
> -------
> 
> Tested with both "regular" INI KSharedConfigPtrs, and they are registered, found and unregistered just fine.
> Tested with a backend plugin, and that also works.
> 
> 
> Thanks,
> 
> Aaron
> 
>