[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Legacy code problem in libkdegames/kgame
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2011-12-31 2:37:12
Message-ID: BDB08D99-14AD-428E-90AE-13F0A844BA80 () gmail ! com
[Download RAW message or body]

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);
>>    =85.
>>  }
>> =

>> This compiles in most environments (apparently) but failed to compile wh=
en
>> I used Macports to port kdegames 4.7.4 to my Apple Macbook.  The offendi=
ng
>> header is referenced by KFourInLine.  I am still investigating the detai=
ls,
>> 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 witho=
ut
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 exper=
imenting
with Clang.  Some things fail, but the Macports team would like users to te=
st 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 =85 :-) =85 but Clang does seem to be the way of the f=
uture ...

>> =

>> 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 Macp=
orts
>> 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 co=
de.

I guess I was implying that the release guys must test-compile it first.  O=
ne would
hope they do =85 :-)

> 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 =85 :-)

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

Perhaps it is high time for a review and renovation of our KDE Games librar=
ies?

Cheers, Ian W.

_______________________________________________
kde-games-devel mailing list
kde-games-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel
[prev in list] [next in list] [prev in thread] [next in thread]