[Kde-games-devel] GIT Conversion status

[Ian Wadham]

On 12/05/2012, at 2:26 AM, Trever Fischer wrote:
> On Fri, 2012-05-11 at 21:53 +0530, Viranch Mehta wrote:
>> On Fri, May 11, 2012 at 8:01 PM, Trever Fischer
>> <tdfischer at fedoraproject.org> wrote:
>>> Could you please shed some light on how this can be achieved using
>>> cmake?
>>> Or better, a specific example?
>> 
>>        Erm, you mean to build two totally different UIs from one
>>        codebase?
>> 
>> I mean how to implement the switch in cmake using which one can choose
>> whether to build qml version of the game or the existing one at build
>> time?
> 
> So, two totally different UIs from one codebase. Thats twice the code
> that needs maintained, so I really wouldn't go about it that way.
> 
> However, here's how you can go about it.
> 
> option(BUILD_QML "Build the QML version" NO)
> option(BUILD_QWIDGET "Build the QWidget version" YES)
> 
> if (BUILD_QML)
>  add_subdirectory(qml)
> endif()
> if (BUILD_QWIDGET)
>  add_subdirectory(qwidget)
> endif()

Well, that's one way … and there are others.  CMake is quite flexible.
But I would not necessarily be looking at two sub-directories of "src"
in such a small game.

> So, two totally different UIs from one codebase. That's twice the code
> that needs maintained, so I really wouldn't go about it that way.

Let's talk realities.  How Viranch achieves separate builds in one CMake
is a minor part of the problem.  If necessary, he could use QMake to get
started, provided he works with the same set of files (old and new), building
and installing the subsets of those files he needs.

I just did a very quick survey of the KBreakout code.  There are about
3,600 lines of C++ there, of which only about 900 are GUI or graphics
painting.  The boot is on the other foot.  The problem is how are we
(the KDE Games team) going to maintain not just two relatively small
UIs, but also two game engines that are about three times larger.

If we are talking about converting many games to QML in the future,
we have to solve that problem over and over again, for about 40 games,
and several hundred thousand lines of code.  We do not have the resources
to re-write all of it and I, for one, certainly do not have the desire to do so.

Within KBreakout src directory there are 12 to 15 files that seem to relate
to GUI and graphics painting.  They account for about 25% of the code.

The other code supports six graphics themes in .svgz files, multiple levels
provided from an XML level-set file, multiple types of gifts, some simple
sounds, scoring, high scores, rules and of course the game's dynamics.
There is also a rendering system (from the KDE Games library) that creates
and caches pixmaps, scaled according to the window or canvas size selected
by the end-user from time to time.

It seems to make sense that you should re-use some of this code.  Maybe
you will need to modify it in small ways, such as adding property macros or
re-defining methods as slots.  Maybe you will need to do more than that, but
hopefully not in such a way as to make the classes incompatible with the
other existing code.

Within the time available, and bearing in mind that this is a GSoC exercise, it is
unlikely that you can re-use a lot of this code or reproduce all of the features
of the current KBreakout.  But we expect you to show us how it can be done
and how the QML code can integrate with our library code.

Maybe you will choose to implement a simpler version of KBreakout at first,
as a proof of concept, but hopefully not too simple.  And it should include some
of the larger game's features.

If what you produce can be extended to incorporate all the features of the
current KBreakout and does get extended, then and only then can we
consider replacing the current version with the QML version.  Until then,
we will need both: one as a production version and the other as a prototype
future version.  The more shared code they have, the easier it will be to keep
both of them fully developed and/or maintained.

Cheers, Ian W.