Changes into KConfigSkeleton between kde3.x and kde4.0
schumacher at kde.org
Wed May 16 23:38:08 BST 2007
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
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. (With the
changed behavior the name of the function also wouldn't fit anymore).
Cornelius Schumacher <schumacher at kde.org>
More information about the kde-core-devel