Kolf: Rumours of its death have been much exaggerated

[Stefan Majewsky]

I'm forwarding the following mail to k-c-d and release-team on request of its 
author:

Am Sonntag 05 Juli 2009 03:16:17 schrieb Ian Wadham:
> Hi guys,
>
> I have just committed a fix to Kolf on trunk/kdegames/kolf.
>
> The only problem seems to have been that ::openFile() in
> kolf/game.cpp relies on the list of groups in the Course
> file being sorted, so that all groups for one hole appear in
> sequence.  Otherwise, it gives up after reading and loading
> the first group.
>
> The group names are of the form
> [<hole-number>-<object-name>@<x>,<y>|<id>], where
> <object-name> is "cup", "ball", "slope", etc.  So no wonder
> things looked bad if only one object per hole was being
> loaded and painted !!!
>
> I am unsure whether kolf/game.cpp, line 2740, should ask for
> KConfig::SimpleConfig, so I have left it as KConfig::NoGlobals.
> It seems to make no difference in this case.
>
> Stefan, Mauricio or whoever, please can you try out this fix.
>
> If it is OK and there are no further problems, the fix should
> be backported to the KDE 4.3 branch.  Would you like me
> to do that?
>
> Stefan, I am not sure where you are up to in discussions
> with release-team at kde.org and kde-core-devel at kde.org.
> I am not subscribed to either list.  Someone should tell
> them the news.
>
> I am CCing you, Stefan and Mauricio, because I am getting
> only my own stuff back on kde-games-devel.  I can only
> assume you have not seen my "Hope for Kolf" posts ... ;-)
>
> Also has anyone tried out the latest KGoldrunner sounds?
> I am waiting to backport them to the KDE 4.3 branch.
>
> BTW and on another topic really, my fix to Kolf poses some
> interesting questions about "semantic drift" in libraries.
>
> As I mentioned on another thread, I have KDE 4.2, KDE 4.3,
> Qt 4.4 and Qt 4.5 all installed in my dev setup and I can mix,
> match and compare.  Without that, I would not have had no
> hope of finding this bug in Kolf.
>
> In KDE 4.2, the KConfig::groupList() functions delivers
> group names in sorted order in a QStringList, but in KDE 4.3
> the names are not sorted, even if they were in the actual file,
> as is the case in Kolf's Course files.

There have been some changed in KConfig::groupList between KDE 4.2 and 4.3: 
[1] does not look suspicious (does not change the iteration order), but [2] 
changes the temporary result storage from QStringList to QSet<QString>, which 
is most probably the cause of problems.

[1]http://websvn.kde.org/?view=rev&revision=874147
[2]http://websvn.kde.org/?view=rev&revision=931254

> In Qt 4.4, QStringList::sort() returns another QStringList,
> whereas in Qt 4.5 it is VOID.  I thought that kind of thing is
> not supposed to happen in Qt.  With the Qt 4.5 ::sort(), I am
> assuming that it sorts the current QStringList in situ, but the
> doco does not actually spell that out ...

QStringList::sort() has always been void, see for evidence:
  http://doc.trolltech.com/4.4/qstringlist.html#sort
  http://doc.trolltech.com/4.5/qstringlist.html#sort
(I also tried to check a nearby machine with Qt 4.3, but I cannot reach it 
currently.)

> Of course, it was wrong of Kolf's author to assume the group
> names were sorted --- or maybe that was a documented
> feature in KDE 3(?), when Kolf was written.  I would say
> the assumption is excusable, though.  So much of the time,
> in KDE, one has to second-guess what a library-function does
> --- or try to read the code --- because the doco may be brief.
>
> The alternative is not to use that KDE function unless you
> absolutely have to.

I think the main problem here is the unexpected usage: No library developer 
ever intended that important information be encoded into the group names. I've 
also found the course file format of Kolf 1 quite quirky, and made the Kolf 2 
course file format cleaner in that regard (see playground/games/kolf-
ng/courses), with extensive use of nested groups.

> All the best, Ian W.

Greetings
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20090705/91db1a11/attachment.sig