Changes into KConfigSkeleton between kde3.x and kde4.0

[Andreas Pakulat]

On 16.05.07 23:35:58, Laurent Montel wrote:
> On Wednesday 16 May 2007 23:03:45 Andreas Pakulat wrote:
> > On 16.05.07 23:00:07, Laurent Montel wrote:
> > > Before it was:
> > >
> > > KConfigSingleton::writeConfig()
> > > {
> > > ....
> > >    save_data_from_kconfigSingleton ;
> > > ....
> > >    and after call: usrWriteConfig();
> > > }
> > >
> > > usrWriteConfig() is a virtual function.
> > >
> > >
> > > After into kde4.0 we have:
> > > KConfigSingleton::writeConfig()
> > > {
> > >     call: usrWriteConfig();
> > > }
> > >
> > > void KConfigSingleton::usrWriteConfig()
> > > {
> > >   save_data_from_kconfigSingleton();
> > > }
> > >
> > > So now data was not stored when we call writeConfig and redefine virtual
> > > function "usrWriteConfig()"
> > >
> > > For me it's a bug.
> >
> > For me its just a behavioural change. And its needed for some use-cases,
> > for example in KDevelop where the KConfigSkeleton's "default" way of
> > storing things into the kconfig object doesn't work.
> 
> What is the problem ?

Hmm, actually I only need this on usrSetDefaults and usrUseDefaults. For
usrWriteConfig KDevelop is fine if it can hook into writeConfig() after
the items have been stored to the configuration.

The reason is simply that KDevelop uses KConfig to store its project
information. To do that it uses 2 files, the normal project file which
is read-only and a developer specific file which any changes are
written to. Now upon setting the default values Kdevelop needs to give
precedence to the values in the project file over the ones in the
developer file (which is used as the KConfig pointer returned by
KConfigSkeletong::config(), so reading/writing uses developer file in
precedence of the project file).

> > So this change 
> > allows users of KConfigSkeleton to do more customization.
> >
> > Instead you can just call the default implementation before or after you
> > did your own stuff, so I don't see a problem.
> 
> I see a big problem, API was not changed (same function) but it doesn't work 
> as previously so it's not good for guy which port application => it will 
> create porting bug.

Apparently Adam forgot to add a proper note to KDE4PORTING.html when he
did the change. And he did this change for exactly this purpose, to be
able to completely re-implement them if needed. I don't know if KDevelop
is the only app that needs full control, or if Adam's current projects
need this too, you'd have to ask him.

> why not revert as previously and use directly usrWriteConfig() when a guy when 
> to customize it. (If guy want to customize it it will re-define this virtual 
> function no ? )

Because that doesn't work, if one really needs to re-implement the
logic. It would work by making read/writeConfig and use/setDefaults
virtual too and then you can remove the usr* things alltogether because
calling the base class is enough.

Andreas

-- 
Expect a letter from a friend who will ask a favor of you.