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

[Viranch Mehta]

On Thursday 20 Dec 2012 11:06:12 PM Albert Astals Cid wrote:
> El Dijous, 20 de desembre de 2012, a les 07:09:15, Viranch Mehta va 
escriure:
> > 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 see, it seems big-ish yeah. Note that all this will go the sooner in 4.11
> in aprox 6 months so there is not an *immediate* rush.

I guess I should be able to get it over with by then.

> 
> > > > 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.
> 
> I don't mind you commiting your changes to KBreakout master provided that
> once the "big qml in libkdegames" gets done you port it to there (having
> copies of the code is bad).

yes, I'm constantly testing the QtQuick support to libkdegames with KBreakout
so the port will be immediately committed to KBreakout once the library is 
ready :)

> 
> Also it will help people running kbreakout from git to give some testing :-)
> 
> Anyone else has any opinion on this?

will commit the QtQuick KBreakout tonight unless someone raises any concern

> 
> Cheers,
>   Albert
> 
> > Cheers,
> > Viranch
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel