[Kde-games-devel] Quality-check for kdegames module created

[Ian Wadham]

Hi Dmitry,
>
> I'll try to reply, but my English skills are limited in some
> complex phrases, so don't bite me :).
>
So maybe you can understand the difficulties I have with KDE
and its doc :).  So many words used are specialist terms or English
words that have a completely different meaning in KDE.

> This is meant to be KDE-internal quality check, but of course
> you can follow its criterias if you wish.
>
Phew!  That's OK then! :)

> "results.php" is a stub.
> It works like this: when developer thinks that certain criterion if
> fullfilled, he edits a corresponding xml file by placing a corresponding
> "check" :).
>
So I can just tick ("check") everything in my app and I'm done? ;)

> > Of the 14 "quality" criteria, only 3 or 4 mean anything to
> > me, and all of them need much more explanation
> I'm a newbie, you know :).
>
So am I, even though I've been at this since KDE 2 and Qt 1, I am
still mystified by much of what goes on in KDE.

> Perhaps someone in this list can enlighten you, or better ask on
> kde-devel at kde.org.  Or maybe even better, check out docs at
> http://developer.kde.org.
>
These are useful, but often seem to finish just when they are
getting to the tricky stuff.  My problem with XMLGUI (*ui.rc)
is how to merge my own menu items with the "standard" ones
correctly and end up with a logical sequence of menu items on
screen (most-used or most important near the top of the list).

>> But why _do_ Qt and KDE keep changing their class interfaces?
> Well, software improves from time to time :).
> It gets new features, etc.  You think it's strange? :)
>
I'm talking about _change_ (amendment, replacement and deletion,
often at a fundamental level), rather than genuinely new features
(such as canvas programming or a forms designer).  New features
are always welcome, if they build upon what has gone before.

> Backwards compatibility is maintained between minor releases.
> Staying backwards compatible means not to introduce revolutionary
> features.  Major releases are "Major", because they tend to break
> all the stuff to bring a whole lot of new features, quality etc etc.
> After that things are settled down until the next major release.
>
I beg to differ.  Revolutions do not _have_ to destroy what has
gone before and object-oriented libraries can give us a way to keep
older source code working even while new features are introduced.

A good example is the latest KMessageBox, which now has a
"Don't tell me this again" feature.  It's an extra parameter that you
do not have to use and which defaults to "off", so old code works.
There are also new methods that turn such messages back on again
(something I have often wished I could do when using
Microsoft applications ;-( ).

So my "quality criterion" for libraries is that new features should
be _additive_ and _optional_.  They should not change/delete
class names, method names, parameter names, parameter types,
nor, more importantly, should they change the meaning and keep
the name the same.  That way we can all reduce application
maintenance considerably.

By contrast, (lists have been around in programming languages
for about 50 years), I would think that Qt could have got the rather
fundamental idea of lists settled, without going through 2 or 3
"Major" versions.  I hope Qt4's QList will be the last!

> > I do not wish to become like Alice and the Red Queen,
>> always running hard just to stay in the same spot.
> Whew, my English-part of brain is tired ...
>
"Alice in Wonderland" and "Alice Through The Looking Glass"
are classic childrens' books in English.  They were written by
an Oxford University mathematician for the daughter of a friend,
but adults have found all sorts of deeper meaning in them.  The
episode with the Red Queen is in "Through The Looking Glass".
You might enjoy reading those books, Dmitry, if you have not
seen them before.

> Hope that at least some of my writings were understandable ;).
>
No worries, mate :)  All the best, Ian W.