[Kde-games-devel] GIT Conversion status

[Ian Wadham]

On 11/05/2012, at 7:21 PM, Viranch Mehta wrote:
> On Fri, May 11, 2012 at 2:34 PM, Ian Wadham <iandw.au at gmail.com> wrote: 
> We do NOT want a fork of KBreakout, just two ways to CMake the code: into an
> app using QML or an app structured as it is now.
> 
> Could you please shed some light on how this can be achieved using cmake?
> Or better, a specific example?

No, but i see no difficulty, provided you can build and install a QML app using CMake.
All the QML examples I have seen use QMake.  It is not difficult in CMake to have
two alternative but overlapping sets of source files being built or installed and to
have one target or another being built.

> Also, do we really want this? I mean, QML is for both desktops as well as mobiles,
> so I don't see a reason for keeping the existing version alongside.

Firstly, have a look at http://techbase.kde.org/Schedules/KDE4/4.9_Release_Schedule
Whatever you write, Viranch, there is no chance that it can be released with KDE 4.9.
Therefore we will have to release the existing version of KBreakout.  Meanwhile, your
version will be there in the background.  It would be nice if we were not having to
maintain two completely separate code bases for KBreakout.

Secondly, the features of the QML version you will produce are not yet known.  So we
do not know yet whether it will replace every feature of the existing version.  Indeed,
we are not expecting you to replace every feature in the time you have available.  So
what you produce is unlikely to be a full replacement for the existing KBreakout until
further work has been done on it.

Thirdly, there is no guarantee that what looks good on a mobile phone will also
look good and behave well on a desktop.  Nor can we be sure it will fit in with the
consistent look and feel we try to achieve on a desktop.

What we hope you will help us find out is to what extent we can use existing KDE
Games code and libraries in conjunction with QML.  KBreakout is not a very complex
game, so it would be possible to rewrite the whole thing in QML and Javascript, but
that would not tell us anything about how to convert more complex games to QML.

Perhaps you missed the discussion on the thread "What are the deliverables for KDE
Games GSoC?" last month.  If so, please have a look at it.

The thread started at http://lists.kde.org/?l=kde-games-devel&m=133506459519345&w=2

Stefan's reply at http://lists.kde.org/?l=kde-games-devel&m=133530335304624&w=2 is
important.  It was he who conceived the idea for the QML game project in GSoC.  I have
just been passing on his ideas earlier in this "GIT Conversion status" thread.

The complete thread is item 4. at http://lists.kde.org/?l=kde-games-devel&r=1&b=201204&w=2
The first post was on 24 April and the last one on 30 April.

It seems that the kind of thing Stefan and I are talking about is quite achievable in QML.
http://qt-project.org/doc/qt-4.8/demos-declarative-minehunt.html is an example, but it does
not have all the extra features KMines has.  If you were working on QML-izing KMines, we
would expect you to produce something with more features than Minehunt, but perhaps
not as many as KMines.

Cheers, Ian W.