[Kde-games-devel] KBreakout's QML port

[Viranch Mehta]

sorry for the late reply

On Sun, Dec 16, 2012 at 11:46 PM, Albert Astals Cid <aacid at kde.org> wrote:

> El Dilluns, 17 de desembre de 2012, a les 02:52:57, Viranch Mehta va
> escriure:
> > I was planning to make a review request(?) for the same after my patch to
> > libkdegames for QtQuick support is accepted. Unfortunately that seems to
> be
> > taking some time for me.
>
> What's wrong?
>

The QtQuick port includes a CanvasItem QML component to show theme sprites
from SVGs in QML views using the KGameRenderer object of the game. Since
QML conponents need to have a default constructor, I had to set the
renderer object statically in the CanvasItem after the renderer object is
passed to the QML view (KgDeclarativeView).

This created problems when we needed to have multiple KgDeclarativeViews
with multiple renderer objects. As a result, I decided to create a Renderer
QML component that would represent a KGameRenderer object and that Renderer
QML component can be used to specify the KGameRenderer object to use in
each of the CanvasItems (via the "renderer" property) used in the game,
eliminating the need for setting things statically.

Also, for asynchronous loading of theme sprites, CanvasItem component has
to be a subclass of KGameRendererClient (and reimplement receivePixmap to
show the sprite on the view), which needs KGameRenderer object in its
constructor. But we want to set the "renderer" after the CanvasItem has
been constructed. So I'll have to change the CanvasItem to load the sprite
synchronously which doesn't need KGameRenderer at construction time.

All this transformation is kind of huge and complicated for me, plus the
d-pointer thing is also new for me. So need time to figure it all out.


>
> > I'm not sure if taking up KBreakout's QtQuick port before the patch is
> the
> > right way to go or how to take things further.
>
> Does KBreakout's QtQuick port need libkdegames QtQuick support?
>

For now the components needed (discussed above) are put in KBreakout's
source itself. Here, there's no question of multiple declarative views, so
the above problem is irrelevant for KBreakout. Also, the components carry a
libkdeclarative dependency from kdelibs, if it matters.

Cheers,
Viranch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20121220/fe931937/attachment-0001.html>