[Kde-games-devel] Legacy code problem in libkdegames/kgame

[Ian Wadham]

On 31/12/2011, at 4:48 AM, Albert Astals Cid wrote:
> El Dijous, 29 de desembre de 2011, a les 13:13:44, Ian Wadham va escriure:
>> In libkdegames/kgame there is a header file kgamepropertyarray.h which
>> contains a definition for class KGamePropertyArray.  In this class there is
>> a method declaration and definition as follows:
>> 
>>  void sort()
>>  {
>>    QByteArray b;
>>    QDataStream s(b, QIODevice::WriteOnly);
>>    ….
>>  }
>> 
>> This compiles in most environments (apparently) but failed to compile when
>> I used Macports to port kdegames 4.7.4 to my Apple Macbook.  The offending
>> header is referenced by KFourInLine.  I am still investigating the details,
>> so I do not yet know whether KFourInline actually uses
>> KGamePropertyArray::sort(), but I thought I should draw this problem to the
>> KDE Games group's attention, seeing as we are so close to a KDE SC 4.8
>> release and (I think I read somewhere) there might be no more releases on
>> the KDE SC 4.7 branch.
> 
> Yes, 4.8.0 is close and there will be no more 4.7.x

It looks as though that whole void sort() method can be commented out without
loss to current KDE Games code.  See my other emails.  Maybe whoever looks
after libkdegames can do that in 4.8.1 or later.

Also, maybe Parker or Coolo could fix what appears to be a cosmetic error
in the KPat code.

The problem with 4.7.4 compilation in Macports might be fixed by specifying a
more lenient compiler on the "sudo port install kdegames4" command-line.  I have
not tried that yet.  Macports has moved to a major new version and is experimenting
with Clang.  Some things fail, but the Macports team would like users to test as much
as possible.  At the worst, the kdegames4 @4.7.4 port will need a patch at the
Macports end of the line, since there will be no 4.7.5.

>> What I wonder is whether anyone else has any ideas, fixes or workarounds for
>> this?
> 
> I have two ideas:
> * Your Qt4 is compiled without Qt3 support (i'd bet this is the issue)

Possibly, I will try with another compiler and if that fails enquire on the Macports
list.  Certainly the KDE Games 4.5.x port compiled OK for me back in June, but
compilers, the KDE Games port, Macports itself and Mac OS X have all moved on
considerably since then.  FWIW Macports still has old ports of Qt3 and KDE Games 3,
so it definitely has a need to segregate dependencies on Qt 3 and Qt 4.

> * Clang does not know how to cast an enum to an int
> 
>> I also wonder how this code compiles at all in KDE Games' day-to-day work
>> and in KDE SC releases?
> 
> Because it's using
> 	QDataStream ( QByteArray * array, int mode )

I'll Ignore that bit … :-) … but Clang does seem to be the way of the future ...

>> 
>> In Qt 4.7, QDataStream can have a constructor with a const QByteArray & and
>> no second parameter, so the QByteArray must have read-only mode.  Or it can
>> be constructed with a QByteArray * and a second parameter for the mode,
>> which can then be ReadOnly, WriteOnly, etc.
>> 
>> Neither constructor matches the existing code, so whatever compiler Macports
>> is using is quite right to flag an error, but why don't other compilers,
>> especially the ones KDE releases use?
> 
> "KDE releases" use no compiler, we just release tarballs of uncompiled code.

I guess I was implying that the release guys must test-compile it first.  One would
hope they do … :-)

> As said the code is fine if your platform supports Qt3 support.
> 
>> The code in question seems to be a holdover from Qt 3 days.  See:
>> http://doc.qt.nokia.com/3.3/qdatastream.html#QDataStream-3
>> The constructor with plain QByteArray and a mode was allowed back then.
> 
> It is still allowed if you are compiling with Qt3 support and we are (in the 
> platforms that have this library).

It seems only yesterday (well maybe 4 or 5 years ago) since we KDE Games
writers were being beaten about the ears and threatened with being drummed
out of the regiment if we kept any vestiges of Qt 3 in our code … :-)

So why is our library still relying on Qt 3 support?  And how can that be justifiable?
Qt 3 support was at best a lash-up job.  For example, Mauricio found that Q3Canvas
ran like a truck, very early in the KDE Games conversion process, and he and I had
to abandon its use in KGoldrunner.

Perhaps it is high time for a review and renovation of our KDE Games libraries?

Cheers, Ian W.