KControl modules diagnosis tool

[Frans Englich]

Hello folks,

I have written a diagnosis tool for KControl modules, which outputs a XHTML 
report, a copy from a run is attached.

So, it spots bugs, and gives an overview of what goes on. Hopefully, it will 
be practical for taming this horde of craziness.

If anyone have ideas of what further can be done with this, such as adding 
additional tests, cross tests, or reporting other data; I'm interested. 
Adding new tests is easy, a couple of C++ and XSLT lines.

I've tried testing if translation catalogues are properly loaded by the 
modules, but the modules turns out to be less buggy than the tester ;-) All 
it requires is debugging and investigation from my side, but those interested 
can have a look at the attached "translation.txt"

If it is compiled, which goes just fine with HEAD btw, the output will differ 
slightly from what I attached, because some modules workaround a weird bug in 
KControl(which I will fix in the coming days..). It isn't a big difference 
anyway.

It currently only tests KControl modules, but one possibility is to add a 
bogus category which only KCMRegTester cares about, and then patch all module 
desktop files so they can be found. Is there an interest for this? It would 
impact on the code we ships(small performance penalty, AFAICT), I'll let 
someone else judge if that's a sensible solution.

Back to the content: What this actually is, is a gigantic TODO :) If anyone 
would like to infiltrate KDE or find easy work, here's tons to do:

1. Pick one of the modules
2. Locate it in CVS, look up who have written it, and add a 
setAboutData( ... ) call in the constructor. Checking `cvs annotate` and `cvs 
log` for the files, and peeking at file headers usually tells who have poked 
at the code
3. While at it, add a Quick Hell: call setQuickHelp( i18n( "..." )) in the 
constructor
4. Produce a patch, and send it to kde-devel or preferable the maintainer if 
such one exists.
5. Rinse and repeat

Many of the existing Quick Helps can be improved. Some of them are system 
oriented and needs to be changed to be worded functionally and use phrases 
suitable for users(for example, "here you can configure SAMBA" doesn't help, 
because users don't know what SAMBA is). Existing Quick Helps can also be 
improved. For example, "Here you can configure Y" isn't very helpful when the 
module's name is "Y"(since, duh, KControl is only about configuration, and 
the module's name already told me it's about Y).

It's also possible to convert modules to KConfigXT: A charm with KCModule's 
KConfigXT helper functions.. If a module needs kdeglobals KConfigXT support: 
mail me.

If I can be of assistance in anything, I will gladly help.


Cheers,

		Frans







-------------- next part --------------

With the current code, about 18 modules are reported to not have any translation catalogues loaded, which from anecdotal eveidence is quite wrong. The code which tries to generate it, situated in a loop which iterates over each module, is:


			/*
			 * Later on we check if any translation catalogues have been loaded,
			 * so unload all previous ones.
			 */
			KLocale *locale = KGlobal::locale();
			QValueList<KCatalogue> catalogueList = locale->catalogues(); // Note
			QValueList<KCatalogue>::iterator kit;
			for( kit = catalogueList.begin(); kit != catalogueList.end(); ++kit )
				locale->removeCatalogue( (*kit).name() );

The detection code looks like this:

			/* Translation Catalogues */
			kdDebug() << "\tchecking translation catalogues..." << endl;
			QString catalogues;
			catalogueList = locale->catalogues();
			for( kit = catalogueList.begin(); kit != catalogueList.end(); ++kit )
				catalogues += (*kit).name() + " ";

			kcm.setAttribute( "catalogues", catalogues.stripWhiteSpace() );
			if( catalogueList.count() < 2 )
				kcm.setAttribute( "suspiciousCatalogues", "true" );
			else
				kcm.setAttribute( "suspiciousCatalogues", "false" );


Possible causes:
* KCModule creates an own KInstance, sometimes
* Mixup between KLocale->d->catalogNames and KLocale->d->catalogues. catalogues() returns the latter.

Locally, I have patched KLocale for adding the catalogues():

Index: kdecore/klocale.cpp
===================================================================
RCS file: /home/kde/kdelibs/kdecore/klocale.cpp,v
retrieving revision 1.360
diff -u -3 -p -r1.360 klocale.cpp
--- kdecore/klocale.cpp	7 Sep 2004 11:42:17 -0000	1.360
+++ kdecore/klocale.cpp	17 Sep 2004 17:48:45 -0000
@@ -2229,6 +2229,11 @@ QString KLocale::calendarType() const
   return d->calendarType;
 }
 
+const QValueList<KCatalogue>& KLocale::catalogues()
+{
+	return d->catalogues;
+}
+
 const KCalendarSystem * KLocale::calendar() const
 {
   doFormatInit();
Index: kdecore/klocale.h
===================================================================
RCS file: /home/kde/kdelibs/kdecore/klocale.h,v
retrieving revision 1.162
diff -u -3 -p -r1.162 klocale.h
--- kdecore/klocale.h	9 Sep 2004 19:55:33 -0000	1.162
+++ kdecore/klocale.h	17 Sep 2004 17:48:45 -0000
@@ -23,6 +23,8 @@
 #define _KLOCALE_H
 
 #include <qstring.h>
+#include <qvaluelist.h>
+
 #include <kdelibs_export.h>
 
 class QStringList;
@@ -1102,6 +1104,14 @@ public:
    */
   static QString _initLanguage(KConfigBase *config);
 
+  /**
+   * @returns a list of all loaded catalogs, contains one 
+   * instance per catalog name and language
+   *
+   * @since 3.4
+   */
+  const QValueList<KCatalogue>& catalogues();
+
 #ifdef KDE_NO_COMPAT
 private:
 #endif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kcmregtester.xhtml.bz2
Type: application/x-bzip2
Size: 12016 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040917/afb019e5/attachment.bin>
-------------- next part --------------
_______________________________________________
kde-usability mailing list
kde-usability at kde.org
https://mail.kde.org/mailman/listinfo/kde-usability