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

[Richard Dale]

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.

-- Richard