Kolf: Rumours of its death have been much exaggerated
majewsky at gmx.net
Sun Jul 5 14:24:13 CEST 2009
I'm forwarding the following mail to k-c-d and release-team on request of its
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:
 does not look suspicious (does not change the iteration order), but 
changes the temporary result storage from QStringList to QSet<QString>, which
is most probably the cause of problems.
> 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:
(I also tried to check a nearby machine with Qt 4.3, but I cannot reach it
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20090705/91db1a11/attachment.sig
More information about the release-team