Quality checks (again)

[Andras Mantia]

On Monday 20 March 2006 17:17, David Jarvie wrote:
> On Monday 20 Mar 2006 11:21, Andras Mantia wrote:
> >So hereby I propose some items that should be checked for KDE4
> >(libraries and applications). Naturally some of them are library
> >specific, others are application specific, but the implementation
> > can deal with this problems.
>
> The list should state which checks apply to applications and which
> apply to libraries, so that there is no room for doubt.

Here is some extra information about the checks:

1. Ported to Qt4:

Maybe call ported to Qt/KDE4. Means that all the code is completely 
ported to Qt/KDE4, without using Qt3Support or KDE3Support classes.
Valid for both applications and libraries.

 2. Doxygen documentation exists
Public classes and their methods are fully documented with doxygen tags. 
Valid for installed libraries, but recommended for applications as 
well.

 3. Regression test suite exists
Automatic tests (previously make test) are written. 
Valid for libraries, might be useful for some kind of applications (eg. 
those having a parser).

 4. Follows the coding conventions
If the module (like in case of KDE libraries) or the application has a 
fixed coding convention, it should be verified that this convention is 
indeed followed. 
Valid for both libraries and applications.

 5. Uses KIO for file access (network transparency)
If an application deals with files, it should use the KIO methods to 
access them instead of QFile or system calls. There are of course 
exceptions as there is no need for network transparency for a lilo 
config editor. 
Valid for applications.

 6. Uses KConfigXT
The configuration system is based on KConfigXT instead of simple using 
KConfig. This means that the possible options are described in an XML 
file and there is a preprocessor tool which creates C++ code from this 
XML file. It makes possible to document your options and as I 
understood, your application will be automatically KIOSK aware.
Valid for applications.

 7. KIOSK aware (merge with 6?)
The settings of your applications can be locked down with the help of 
KIOSK methods ([$i] in the config file). Means that if the global 
config file (or in a config file from a profile matching the user) has 
an entry with [$i] after it, the setting cannot be changed by the user, 
and if he/she changes in the local config file, it will be ignored.
Valid for applications.

 8. Uptodate handbook
There is a handbook for your application and it is valid for the current 
version (screenshots are uptodate, all functions are described, there 
is no reference to menu items that do not exist anymore and so on).
Valid for applications.

 9. Uses .ui files
The user interface (the dialogs) inside the application are created with 
Qt Designer.
Valid for applications.

 10. Uses XMLGUI 
The main user interface is described with the help of XMLGUI. I know 
there are some discussions about XMLGUI's future (but I already 
suggested there to keep for KDE4...).
Valid for applications having a mainwindow.

 11. No icon issues (uses the standard icons or provides icons and 
installs to the right place)
See also Olaf's mail. 
Valid for both libraries and applications.

And to make it clear: most of the checks cannot be automated, it is up 
to the maintainer or somebody from the project to check if the 
application complies or not to the requirements.

Once the final checklist is approved, I will change the website and 
include the detailed descriptions with link to howto/tutorial pages if 
they exist.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- 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/20060320/b8997484/attachment.sig>