Quality checks (again)

[Thiago Macieira]

Andras Mantia wrote:
>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.

I don't agree. It should apply only to the core libraries.

I see no problem in applications using to KDE3Support classes or 
Qt3Support classes or methods. It should be a goal to clean that up for a 
future release, though. We at Trolltech put a lot of effort into 
Qt3Support to make it useable for more than just a "mandatory step" in 
porting to Qt4: it's supposed to be useable and used.

What is important is that the public API does not expose deprecated 
methods/classes from KDE3 and Qt3.

> 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).

This is very difficult to judge. A basic test suite should be required for 
all classes, but given our difficulty in finding maintainers for our 
existing classes, it'll be even more difficult to find people to write 
testcases. Not to mention a comprehensive one.

> 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.

Of course, this only applies for URLs. Once you obtain a local path for 
the file (if one can be obtained), using QFile is acceptable.

Random access to files requires QFile anyways. We don't plan on adding 
random file access to KIO.

> 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.

Valid for libraries that load settings too.

> 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.

Again, valid for libraries too. But I don't think it should be merged: 
making settings documented and using KXConfig and preparing a KIOSK mode 
are two completely different use-cases. The configuration locking is done 
at the KConfig-level or deeper (backend). There's nothing the application 
author needs to do to enable it.

Besides, I'm not sure if this is a point at all. Some applications are not 
supposed to be used in KIOSK-mode at all. A very simple example 
is "konsole". If you allow a user to run it, there's nothing stopping him 
from loading other programs or doing operations that you've forbidden in 
other places (such as file erasing in Konqueror).

I think this could be an "extra item": applications that do intend to be 
used in a KIOSK environment would get a "KIOSK-certified" 
seal/award/stamp/whatever and would document what can and cannot be 
locked down. This also means the authors accept bugs for failing to 
comply to the KIOSK settings.

> 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.

Questions: How about KParts? Since KParts can add items to the UI, where 
does that documentation go?

Example: Kile loads KPDF, KGhostview and KDVI to show the generated 
document (hopefully, it'll load oKular only in KDE4). I don't suppose we 
want the Kile authors to document the oKular interface.

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

And KParts.

>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.

This is also the checklist that should be applied for promotion from 
kdereview to extragear. (playground-to-kdereview promotion should happen 
on author request)

We should also instate a policy of demoting from extragear to kdereview, 
somehow.

-- 
Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech AS
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060320/7fb055ed/attachment.sig>