fix my KCModule issues once and for all

[Matthias Kretz]

On Thursday September 25 2003 20:43, Roger Larsson wrote:
> On Thursday 25 September 2003 19.32, Matthias Kretz wrote:
> > Well, after I commit my patch the "emit changed" is done automatically -
> > KControl does it itself and KCMultiDialog uses KCModuleDecorator to do
> > it. So after a load() or save() "emit changed( false )" is called. I
> > don't call "emit changed( true )" after defaults(), because it could very
> > well be that the current settings are the defaults - so pressing the
> > button didn't change any settings. I'm not sure if it's a good thing to
> > do usability wise since the user might expect the apply button to be
> > enabled after clicking "Defaults" (so this is up for discussion).
>
> Not good.

What is not good?

> > In the rare case that saving failed and the KCM would like to keep a
> > changed state you would call:
> > QTimer::singleShot( 0, this, slotEmitChanged() );
>
> Even worse! :-(
>
> > with that slot calling "emit changed( true );".
>
> Rule: The Decorator should - heal, support but never hurt

I don't know what you mean, since that's what it's doing.

> But I think that whatever the final solution is - kdevelop template SHOULD
> be correct. What is worse is that kdevelop templates might need to work for
> older KDE versions.
>
> So what was really wrong with adding "setChanged( ... );" where needed?

setChanged was an invention from me to get a sane changed state handling for 
KCMs which KCMultiDialog needs. setChanged does not exist in KDE versions 
prior to 3.2 and if I commit my 2nd patch it will not exist in 3.2, too.

> Could the Decoration use a second object and compare? Something like this?

Not possible. First of all the interface doesn't provide it - second it would 
be a real pain to implement that for every single KCM instead of just fixing 
the changed signals.
Oh, and I almost forgot - you cannot copy QObjects.

I guess I should write a small explanation of what I'm doing and why:
Up to and including KDE 3.1 KCMs would just emit changed( true ) whenever some 
input widget was changed. Almost none of the KCMs ever bothered with emitting 
changed( false ) if the config on disk and on screen were equal (like after 
calling load() or save()). Since I needed that in KCMultiDialog (I don't want 
to go into details here) I began my quest to "fix" all KCMs we have in CVS. 
I've not seen a single KCM that would not need to emit changed( false ) in 
load() and save() and changed( true ) in defaults(). So it's pretty stupid to 
add that to all KCMs if we can do it automatically. I was searching for a way 
to do it automatically and that's what my patches are about. I have thought 
long and hard :-P to think of a situation where the signal should not be 
emitted and it is theoretically possible. For those 0.1% a single shot timer 
should really be good enough. We could add a method to the KCModule interface 
to handle that case, but I don't think it's justified.

-- 
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: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030925/46875918/attachment.sig>