[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Add ability to define which KConfigBackEnd to use
From:       "Thomas Braxton" <kde.braxton () gmail ! com>
Date:       2010-06-04 13:20:47
Message-ID: 20100604132047.14581.99129 () localhost
[Download RAW message or body]


-----------------------------------------------------------
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
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]