Changes into KConfigSkeleton between kde3.x and kde4.0

Andreas Pakulat apaku at
Thu May 17 00:09:03 BST 2007

On 17.05.07 00:38:08, Cornelius Schumacher wrote:
> On Wednesday 16 May 2007 23:35, Laurent Montel wrote:
> > On Wednesday 16 May 2007 23:03:45 Andreas Pakulat wrote:
> > >
> > > 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.
> >
> > 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 ? )
> I agree with Laurent. The behavioral change is a problem. The requirement to 
> call the base class implementation is a constant source of potential and real 
> bugs.

Well, Adam just forgot to add the porting notes - IMHO. And the
requirement to call a base class impl. if you want the default behaviour
is IMHO pretty normal in OO world. In fact I find such things like
writeConfig+usrWriteConfig much uglier and weird than just calling the
base class impl. in a subclass' writeConfig (when this function is

> For the cases where complete control over the way of writing and reading 
> configuration is needed we could make the read/writeConfig virtual. But for 
> the general case I think it would be better to keep the usrWrite/ReadConfig 
> as simple incarnation of the template method design pattern.

Well, I think usr* is just redundant if the normal methods are virtual,
but whatever you guys decide (you know I'm not really a kdelibs hacker
;) is fine with me as long as I can have complete control over the
implementation of those function.


PS: Adam's commits where 560326 and 559982, which is quite some time
ago, I really wonder why people start to notice just now. (yeah I know
porting against moving kdelibs wasn't easy until now)

You can do very well in speculation where land or anything to do with dirt
is concerned.

More information about the kde-core-devel mailing list