Review Request: KLocale: Keep track of original KSharedConfig/KConfig for later use.

David Faure faure at kde.org
Fri Dec 10 19:27:31 GMT 2010


On Friday 10 December 2010, Richard Dale wrote:
> On Sunday, December 05, 2010 12:42:11 pm Oswald Buddenhagen wrote:
> > > On 2010-12-05 09:13:59, Oswald Buddenhagen wrote:
> > > > the kconfig magic is a monstrosity, but it seems reasonably safe.
> > > > though i wonder whether it wouldn't be better to get everything you
> > > > may later need from the config and then just throw it away ...
> > > 
> > > John Layt wrote:
> > >     I had thought of caching the user settings, but they are at a
> > >     per-calendar sub-group level, so that's 10 calendars x 2 or 3
> > >     settings each = 20 to 30 extra values that would need to be stored
> > >     as int's and QStrings when most of the time they will be unused or
> > >     the system default anyway.  I decided in the vast majority of
> > >     cases, i.e. when using the global config with no user calendar
> > >     settings, that a null Ptr was the most efficient solution.
> > >     
> > >     I do wonder if I need to deprecate the constructor and methods that
> > >     take a KConfig* and have new ones taking a KShardedConfig::Ptr
> > >     instead for consistency and safety.
> > 
> > i wouldn't deprecate anything in this commit.
> > in the bigger picture, in kde5 i'd like to merge kconfig with
> > ksharedconfig, so it would probably make sense to deprecate
> > kconfig-taking functions - throughout kdelibs.
> 
> From the point of view of language bindings, I wish there weren't any smart
> pointers in the public KDE apis. They are 100% fine in the private
> d-pointers, but I can't see any need to have them public like
> KSharedConfig::Ptr.

Right. The best solution in KDE 5 would be a KConfig which uses sharing 
internally. If the app creates KConfig("kfoorc") in two places, it gets the 
same underlying KConfigInternal (which would be today's KConfig code).

I could do that to KService, KMimeType, KServiceType... too.

But let's not get ahead of ourselves :-)

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).




More information about the kde-core-devel mailing list