[PATCHES] KCModule changes and kutils fixes

[Matthias Kretz]

Sorry, that I didn't find time before today...

On Saturday 25 August 2007, Rafael Fernández López wrote:
> > ## kdelibs.diff ##
> >
> > I'm not so happy about adding the init method. For this particular case
> > I'd
> > really favor to add the line
> > QTimer::singleShot(0, this, SLOT(changed()));
> > to the constructor. What is "conditional to the system" about that?
>
> With 0 it didn't work for me. With 10 or 100 it did. That makes me nervous.

As you can see in the KCModuleLoader and KCModuleProxy code there's no event 
processing happening between instantiating the KCModule and connecting the 
changed signal. So if 0 doesn't work and 10/100 works you should really start 
debugging as something wrong is happening (some code calling processEvents or 
so).

> > Do you see other use cases for the init method than the one you described?
>
> That one only. I fail to see others. Probably there are more, but certainly
> they don't come to my mind :)

Which is the reason why my gut feeling is against the init method (which is a 
rather common (private) function name, btw, in many classes that have more 
than one ctor).

> > Another approach would be to call load() from KCModuleProxy in the place
> > where
> > you call init(). Actually that's how I'd like the KCModule interface to
> > work,
> > but that's a pain to fix in all the KCMs where you have to remove the
> > load()
> > call from their ctor.
>
> That  won't work. I really agree of calling load() where it is loaded
> instead of the constructor of each module. That makes sense and sounded
> strange to me when I saw each module had to call load() individually.
>
> Anyway, load() won't do the trick. The situation was: we have a plugin that
> *needs* to inform about its situation when the button "OK" is clicked on
> its configuration dialog, it doesn't matter if something was changed on its
> configuration dialog or not. load() in all cases what will do is emit
> changed(false).

You're saying load() won't work because it will "emit changed(false)"? But it 
doesn't have to. For your special case the load() function will figure out 
that the configuration it shows is different than what's stored in the config 
file so it can "emit changed(true)".

In summary: I don't think we have enough justification for init().

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
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/20070827/2bb53874/attachment.sig>