KCModule & KConfigXT

[Frans Englich]

On Saturday 10 July 2004 17:36, Matthias Kretz wrote:
> On Saturday 10 July 2004 18:02, Frans Englich wrote:
> > * I removed the constructor because it had no usage scenario: Since it
> > uses the this pointer, the KConfigManager can't find the widgets.
>
> good
>
> > * What about deprecating sysdefaults()? It's not even used in a grep
> > through all kde modules.
>
> From what I know it's not going to be used in any app - so yes, looks like
> this method should be removed.
> This is the cvs log entry for that code:
> 1.6  hoelzer  2000/03/10 09:08:53
> Added a method and a tag to be able to implement system default
> values, as suggested by David Smith.
>
> NOTE: This is not implemented, but I don't want to do changes on
> the API after kdelibs freeze.

I'll mark it as deprecated when I commit the other stuff then.

>
> > * What about:
> >  virtual void load();
> >   // ### KDE 4: Call load() automatically through a single-shot timer
> >   //            from the constructor // and change documentation
> >   //            FIXME: Why not do it now? How can it break?
>
> Well, it's behaviour incompatible, that's the problem. But I can't think of
> a way that this incompatibilty could break anything. So, yes we could
> change it now, but it needs thorough testing.

Argh.. Such a thing makes one's fingers itch, but there is no reason to do 
that change now. I can neither think of anyway it can break, but it's a 
cleanup-change which just as well can be done later on -- for it to be 
useful, the load() calls needs to be removed(otherwise a nice performance 
hit) and its just a bad idea stressing through that before the feature freeze 
and risk any bugs. Sorry for bringing it up.

>
> > * If the patch looks good, apply now(KDE 3.3)?
>
> Looks good enough to me. But I can only speak about the KCM part of the
> patch - I haven't worked with KConfigXT enough yet to say anything about
> it.

Ok, I'll commit Tuesday, unless someone objects.


			Frans