[Kde-games-devel] Review Request: Support for QtQuick in libkdegames

[Ian Wadham]

> On Aug. 9, 2012, 10:50 p.m., David Edmundson wrote:
> > trunk/KDE/kdegames/libkdegames/declarativeimports/canvasitem.h, line 43
> > <http://svn.reviewboard.kde.org/r/7017/diff/2/?file=48265#file48265line43>
> >
> >     If you tried inserting two KgDeclarativeViews in an app, this now breaks heavily.
> >     
> >     In the context of KBattleship (for example) that would be a perfectly sensible looking thing to do.
> >     
> >     However, given a QML creatable item needs to have a default constructor, I can see why you've done this.
> 
> Viranch Mehta wrote:
>     Well I could add a check before to decide whether to call this. This would be assuming, of course, that you want to use a common KGameRenderer for both the KgDeclarativeViews.
>     
>     Is it possible that a single game uses two different KGameRenderers?
> 
> David Edmundson wrote:
>     Then it's KGameRenderer that needs to be a singleton, not a static pointer in the classes using it.
> 
> Ian Wadham wrote:
>     Yes. KGoldrunner when ported to QGV will be using two, because each theme has two SVG files: one for the runners and the other for the background and tiles. Also I believe Granatier already has more than two KGameRenderers.
> 
> Viranch Mehta wrote:
>     Then this also raises the issue of using multiple renderers within single declarative view. It becomes necessary to specify which renderer to use for each CanvasItem instance, which makes this very complicated.
>     
>     A potential solution is writing a QML component for KGameRenderer too, like:
>     
>     KgCore.Renderer {
>         id: backgroundRenderer
>         /* some properties that enable finding the path to the themes */
>     }
>     
>     KgCore.Renderer { id: tilesRenderer; /* ... */ }
>     
>     CanvasItem {
>         id: tile1
>         renderer: tileRenderer
>     }
>     CanvasItem {
>         id: background1
>         renderer: backgroundRenderer
>     }
>     
>     and so on...
>     what do others think?

I am not that well acquainted with QML, so cannot comment. In KGoldrunner I simply wrote a class, KGrRenderer, that hid the fact that there are two renderers and had methods for getting pointers to KGameRenderedItem's for tile, background, etc. I guess you are doing something like that here.

Two advantages of KGrRenderer are that it can hide the translation from the model's internal codes to SVG element names and it can auto-delete when one item is replaced by another (or by empty space), as the game moves from level to level. So it is a bit more than a wrapper for two KGameRenderer's.


- Ian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/7017/#review10919
-----------------------------------------------------------


On Aug. 9, 2012, 9:42 p.m., Viranch Mehta wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/7017/
> -----------------------------------------------------------
> 
> (Updated Aug. 9, 2012, 9:42 p.m.)
> 
> 
> Review request for KDE Games.
> 
> 
> Description
> -------
> 
> This patch contains some new stuff for libkdegames mainly to support future porting of KDE games to QtQuick/QML. Post this patch, libkdeclarative becomes a dependency for libkdegames.
> 
> There are two new things:
> 
> 1. KgDeclarativeView:
> This is a QDeclarativeView with KDE-specific import paths for QML components configured and javascript functions bindings added (like i18n() methods) using the KDeclarative library. If the view is supplied with a KGameRenderer object, it is added to the underlying declarative engine so that it can be used by QML components built for use in QML ports.
> 
> 2. CanvasItem QML component(the name of the component can be changed as per suggestions):
> This is a QML component that simply loads specified sprite pixmap from the theme provided by the KGameRenderer. The component uses the KGameRenderer instance from the engine (as set by the KgDeclarativeView) and loads the theme-specific sprite pixmap. The sprite retrieval is asynchronous and is done by using KGameRendererClient, this has potential for performance improvements.
> 
> The documentation on how to use these is inline with the code.
> 
> The kgdeclarativeview{.h,.cpp} are in libkdegames and the QML component is in declarativeimports/ directory.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdegames/libkdegames/CMakeLists.txt 1309184 
>   trunk/KDE/kdegames/libkdegames/declarativeimports/CMakeLists.txt PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/declarativeimports/canvasitem.h PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/declarativeimports/canvasitem.cpp PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/declarativeimports/corebindingsplugin.h PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/declarativeimports/corebindingsplugin.cpp PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/declarativeimports/qmldir PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/includes/CMakeLists.txt 1309184 
>   trunk/KDE/kdegames/libkdegames/includes/KgDeclarativeView PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgdeclarativeview.h PRE-CREATION 
>   trunk/KDE/kdegames/libkdegames/kgdeclarativeview.cpp PRE-CREATION 
> 
> Diff: http://svn.reviewboard.kde.org/r/7017/diff/
> 
> 
> Testing
> -------
> 
> Tested with my the ongoing port of KBreakout, works as expected.
> 
> 
> Thanks,
> 
> Viranch Mehta
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20120812/93fa1ad5/attachment.html>