Matthias, taking that there has been no change in the module, can it be something 
is broken in kcmmodule? 

BTW: I consider the bug critical. When the modules out there do not work 
reliable - so please make sure kcmmodules work without source change when 
3.2 comes out. 

Subject: Re:  Entering information failes to set the kcm to 'modified'

Well there has been a change in the module (s/emit changed/setChanged/). 
That's what apparently breaks it. The real problem is the module (and I will 
fix 'em all if nobody does before me) but I would like to know first why it 
breaks without the (needed) changes in the KCModule.

The problem is I have not been able to reproduce that behaviour, so I either 
need a list of steps to reproduce or somebody who's seeing that problem needs 
to debug it. I'm very willing to help to find the problem.

Third party KCMs are not affected. The problems started with my 
s/emit changed/setChanged/ in kdebase/kcontrol/*

I got the bug after starting with a clean homedir (rm -rf ~/.kde) 
maybe you can restart KDE after an 'export KDEHOME=~/.kde-test' to try if you can 
reproduce. 
 
Also notice that I installed my machine last night; with absolutely no KDE on it; so I 
have only HEAD on my machine.  Maybe some old libraries are on your machine? 
 
I'll be happy to look into this stuff; but you know I'm not that well versed in the 
subjects.. 

Subject: Re:  Entering information failes to set the kcm to 'modified'

I created a new user and started KDE. Opened KControl selected the Email KCM 
and the KCM was already in "changed" state. I changed some things pressed 
apply and then apply was disabled. I switched to another KCM, switched back, 
changed something switched again and it asked for confirmation.

Using ldd I checked that the libraries it uses are current and I even attached 
gdb to check the libs it uses.

Do you have a way to reliably reproduce it? If yes can you list the steps so 
that I my try?

/me just valgrinded kcontrol: no mem corruption...

In the mean time I have completed the installation of my new system and I am 
surprised that (even after using a different KDEHOME) I can't reproduce it either. 
 
The most logical conclusion I have to make is that my installtion of all kde modules 
somehow fixed this. 
I was running with just kdebase kdelibs at the time I found the bug. 
This includes the many many dependencies I had to install to get those modules 
compiling. (and no, I did not do a cvs update in the meantime :) 
 
Because you were worried about broken source compatability; I downloaded a 
source repository of a project of mine that includes some KCMs written for KDE3.1 
I can tell you that they compiled just fine; and the modified also showed just the way 
I wanted it to. 
 
Only bug left is that the 'apply' was enabled when you entered the mail kcm but no 
modified is shown... 
 

Subject: kdebase/kcontrol/kcontrol

CVS commit by mkretz: 

OK, this should fix the last remaining problem with KControl after my
KCModule changes: The clientChanged( bool ) slot emitted a signal and that
signal was never emitted if the module was already changed in the ctor. So
now it calls clientChanged( true ) if the module is changed but using a
single shot timer since we're in a ctor again.

I also added a big fat warning about broken modules.

CCMAIL: 64602-done@bugs.kde.org


  M +19 -3     proxywidget.cpp   1.58
  M +1 -0      proxywidget.h   1.15


--- kdebase/kcontrol/kcontrol/proxywidget.cpp  #1.57:1.58
@@ -38,4 +38,5 @@
 
 #include <kdebug.h>
+#include <qtimer.h>
 
 class WhatsThis : public QWhatsThis
@@ -221,7 +222,17 @@ ProxyWidget::ProxyWidget(KCModule *clien
   setVisible(_root, run_as_root);
 
+  if( client->changed() )
+  {
+    kdWarning( 1208 ) << "The KCModule \"" << client->className() <<
+      "\" called setChanged( true ) in the constructor."
+      " Please fix the module." << endl;
+    QTimer::singleShot( 0, this, SLOT( clientChanged() ) );
+  }
+  else
+  {
   // disable initial buttons
-  _apply->setEnabled( client->changed() );
-  _reset->setEnabled( client->changed() );
+    _apply->setEnabled( false );
+    _reset->setEnabled( false );
+  }
 
   connect(_help, SIGNAL(clicked()), SLOT(helpClicked()));
@@ -300,4 +311,9 @@ void ProxyWidget::rootClicked()
 }
 
+
+void ProxyWidget::clientChanged()
+{
+  clientChanged( true );
+}
 
 void ProxyWidget::clientChanged(bool state)

--- kdebase/kcontrol/kcontrol/proxywidget.h  #1.14:1.15
@@ -57,4 +57,5 @@ public slots:
   void rootClicked();
 
+  void clientChanged();
   void clientChanged(bool state);
 

No 

To give the bug some flesh: 
 
<pmax> coolo: could you reproduce it yet? :-) 
<coolo> pmax: I start "kcmshell smb", it has disabled apply 
<coolo> then I click the checkbox and it enables apply 
<coolo> I close and restart - apply disabled 
<coolo> then I change the combo box value -> apply enabled 
<coolo> so what is the bug I'm looking after? 
<pmax> what about in KControl? 
<pmax> (ie not with kcmshell) 
<coolo> in kcontrol the module shows apply enabled from the beginning (but has 3 
other sub modules) 
<coolo> when I press reset, both apply and reset get disabled and changes do not 
reenable apply 
<coolo> ASSERT: "!name.isEmpty()" in /home/coolo/prod/kdelibs/kdecore/kinstance.cp 
<coolo> but that module per se is broken anyway 
<pmax> yup 
<coolo> pmax: ah, I didn't have update kcontrol 
<coolo> but it's still reproducable with 
 

Subject: Re:  Entering information failes to set the kcm to 'modified'

OK, the whole thing should work correctly now. (more or less - there are still 
some rough edges in some of that code)
The real bug is in the KCMs though - well the whole KCM framework is very 
unclean with respect to the changed handling. I'll do what I can without 
breaking compatibility.

confirmed