[Kde-games-devel] What are the deliverables for KDE Games GSoC?

[Ian Wadham]

Thank you, Stefan, for your long and considered reply.

On 25/04/2012, at 7:33 AM, Stefan Majewsky wrote:

> On Sun, Apr 22, 2012 at 5:14 AM, Ian Wadham <iandw.au at gmail.com> wrote:
>>  - Re-implement an existing KDE Game using QML/Qt Quick: we are
>>    not looking for a completely new game nor a complete re-write of an
>>    existing KDE Game
>>  - The re-implementation should use as much as possible of existing C++
>>    code in KDE Games and existing KDE Games libraries
>> 
>> These last two points need a lot of clarification.  Stefan, please help.
> 
> I think both points are essentially correct. I ^W We want true QML
> ports which can be deployed in mobile environments where QtWIdgets is
> not available (at least in the upcoming Qt 5 era). At the same time,
> we want to maintain feature parity between the widget-based and
> QMLized code bases.

If I understand correctly, the QWidget class, all its descendants (buttons, etc.)
and all code based on QWidget and descendants is off-limits in QML.  I think
that implies all of the control (UI) and view parts of our games would need to be
re-written in QML.  Is that correct?  Certainly, the QML examples seem to
hand-code even simple buttons, but I had been reading that as "for example"
up till now, not "this is the way we always do things in QML".

> This can realistically be achieved only by reusing the existing
> UI-independent parts of the code (what one typically calls "business
> logic", or "game logic" in this case) as much as possible.
> 
> Furthermore, I recommend that students and mentors in QML projects
> keep two eyes on code base fragmentation: If the student essentially
> forks the widget-based game and develops the QML-based game from this
> point, we will end up with two practically unmergeable codebases. It
> is best if the QML students adopt a mindset which is similar to that
> of the porting projects, and consider their work a big patch for the
> existing application, which is merged back into the original source
> tree at the end of the summer.

Amen to that.  I have made some further comments in Viranch's thread
on "GIT conversion status".

> Ideally, the resulting application code can be built both for the
> desktop (with the traditional QtWidgets-based interface) and for
> mobile (with the QML interface), just by toggling a switch in CMake.
> This will make maintenance much easier.

Yes, indeed.  +1.

>>  - from a complete re-write in QML, with classes we can add to our library;
>>  - through a complete re-write except for the "game engine", with classes
>>    we can add to our library;
>>  - to what I have suggested above, maybe with mods to our KDE Games
>>    library classes to make them easier to use from QML.
> 
> Number 2 sounds good. It does not make sense to rewrite the game
> logic, which is essentially the same regardless of the user interface
> technology. The exception is that logic code might need some
> adaptation in order to provide the interfaces which QML wants.

I am a little worried about game logic that is driven by signals or QActions
triggered by QWidgets, keyboard and mouse events, but I hope that will work
itself out as we go along and that QML code will be readily adaptable.

I am also concerned about what will happen to our emphasis, since KDE 4,
on resizeability, graphics themes, SVG graphics and cacheing.  Will all that
go away?  Or will we be able to incorporate it in QML apps somehow?

Mobile apps seem to have fixed screen formats and full-screen working
only, but those things could change in time.  It seems like only yesterday
that KDE Games were all oriented towards 640x480 screens … :-)

Even Apple had a problem on their hands when they halved the pixel size
and quadrupled the number of pixels on the iPhone.  I think I read somewhere
that they had to hack the library to provide an option to paint four pixels for
one, so that hundreds (thousands?) of apps could still fill the screen.

> (Rule of thumb: QML can see anything which Qt's Meta Object system can
> see: properties rather than getters and setters, QObject instances
> rather than random C++ classes, and so on.)
> 
> The addition of new QML-based components in libkdegames is very much
> desired, just like QtWidgets-based components are an important part of
> the offering in the current libkdegames.
> 
> However, I want to explicitly encourage QML students to first strive
> for an interface that works well for the specific game. When this goal
> has been achieved, we have a solid basis from which we can determine
> which parts of this interface can be generalized for use in other
> games.
> 
> This policy is consistent with the current state of kdegames: Though
> libkdegames offers shared UI components for common tasks, game
> developers have always been very free to choose the interface which
> suits the specific game best.
> 
> With the advent of QML, the development model, as well as the
> interface design model, changes drastically. This means that we need
> to reconsider which parts of the interface are provided by shared
> components. For example, I would really like a shared component for
> game boards with a fixed number of cells. I know from my experience
> (KGameRenderedObjectItem as used in KDiamond, and Tagaro::Board as
> used by static copy in Kolf) that doing this right with QGraphicsView
> is very complicated. On the other hand, I arrived at a usable
> prototype for such a component in only one hour using QML/Qt Quick.
> 
> In this case, QML makes generalization easier than QtWidgets (e.g.
> QGV). It might also be the other way around: I expect to see more
> fragmentation than before outside the game canvas, in the window
> chrome, where the usual menubar-toolbar-statusbar triumvirate is
> replaced by a bigger flexibility of approaches. Something like the
> *bars might emerge again if it works well, but we need not force it
> now.
> 
> As I said, the QML projects are explicitly about experimenting with
> the new possibilities provided by QML and Qt Quick. The experiments
> should lead to one stable game interface, and to the insight which
> parts of this interface can be reused.

Excellent explanation, Stefan.

> P.S. On the practical side of things, I recommend that the QML
> students (and mentors) familiarize themselves with libkdeclarative and
> Plasma's Qt Components implementation. These two components are the
> basis for QML development within KDE. (But don't expect me to be able
> to tell anything more specific about this topic right now; the very
> same point is also on my todolist.)

Could not find libkdeclarative WebSVN equivalent, *code* or *API* anywhere,
not in Google, not in api.kde.org and not by half an hour or so of chasing links
in community.kde.org and projects.kde.org … but I found plenty of culde sacs … :-)
Where *does* KDE hide the crown jewels these days?

OTOH I did find some scraps of information about QML components and plasmoids
and Viranch's name came up a few times there.  He was previously a GSoC
student in Plasma, but bear in mind that he can only be with us full-time until
July 1, because he starts his new job then.

All the best, Ian W.