Extending KCModuleProxy

[Matthias Kretz]

Ok, I won't come around to finish going through that patch today so I rather 
send what I wrote so far...

On Wednesday 17 March 2004 19:42, Frans Englich wrote:
> True, the thing is, kcmoduleproxy.diff is 24kb big and the kcmoduleproxy.
> {cpp,h} is 21.2kb in total - the class is basically rewritten. realModule()
> is rewritten that's perhaps why it appears as moved(in total 99 lines
> removed, 810 added). But I can run it through indent though, should I?

Almost. Still most of the old code that was in there didn't change. And it's 
nice if the diff would show what exactly was changed and what not. Having to 
manually look for those changes somehow defeats the point of a diff.

> > - - The changed signal is not identical to the one of the embedded KCM.
> > The changed signal of the proxy is only emitted if the KCM really
> > changed. If changed() == true and the KCM emits changed(true) the proxy
> > won't emit the changed signal.
>
> Ok, that was my /intention/ too :)
>
> Sorry, you will have to be a little bit more specific. in realModule() I
> do:

I'm sorry this didn't come through as I meant: What I wanted to say was that 
the documentation for the changed signal was wrong where it says: "This 
signal is relayed from the encapsulated module, and is equivalent to the 
module's own changed(bool) signal."
It was supposed to not be the same and has to, after your changes, still 
behave that way (which I think it does, from what I've seen).

[snip the code I wrote myself ;-) ]


> KControl's ConfigModule do lazy loading on ProxyWidget(which loads
> ProxyView which loads a KCModule..). I would say the things KCModuleProxy
> is supposed to do, is of interest for all cases where KCModules are
> used(such as KControl).

If I understand correctly KControl's code can be simplified using the new 
KCModuleProxy?

> Yes, lazy loading was thrown out in my patch but it's back now(AFAICT). It
> was easy to do - I merged realModule and init.

Looks good.

> The removal was intentional because I thought 95% of the cases one module
> would be shown and the rest about 3-5 modules(configure dialogs). But since
> it back, twisted games like in Kontact is possible. FYI, Kontact without
> lazy loading is unacceptable slow.

Even if it's only 3 modules. It still takes awefully long to load one of them 
- think of all the disk accesses. Lazy loading for KCMs is a _must_ IMHO.

> New versions attached(kstdgui committed). kcmultidialog.cpp#351 crashes
> because KCModuleProxyPrivate* d; is not initialized. Which is really weird
> to me since I do it in KCMultiDialog's constructors, AFAICT.

I'll look into this if you give me more time. (I still know that code pretty 
good. But I'm sick and can't concentrate...)

-- 
C'ya
        Matthias
________________________________________________________
Matthias Kretz (Germany)                          <><
http://Vir.homeip.net/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040319/51f499cf/attachment.sig>