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

[Viranch Mehta]

> On Aug. 9, 2012, 10:50 p.m., David Edmundson wrote:
> > I can see why you've done this, but for me this doesn't really work.
> > 
> > However - what I think we can do is make a wrapper round KGameRenderer and turn it into an QML ImageProvider, which may (I've not thought everything through) be a much nicer solution.

That was my first approach, but the problem with it is that the image does not get updated when the theme is changed. A new pixmap is requested only when the "source" property changes, simply changing the theme does not involve changing the source, and hence the image cannot be updated. Also, there is no way to internally trigger an update so a new pixmap is requested when the theme is changed.

So this is the alternative approach I had to choose. What isn't working for you?


> 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.

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?


> On Aug. 9, 2012, 10:50 p.m., David Edmundson wrote:
> > trunk/KDE/kdegames/libkdegames/declarativeimports/corebindingsplugin.cpp, line 28
> > <http://svn.reviewboard.kde.org/r/7017/diff/2/?file=48268#file48268line28>
> >
> >     You're making a proper QML plugin library (which is great!) but it's only usable when existing properties are already applied. 
> >     
> >     This defaults the point of it being a plugin/library.
> >     
> >     You'd be better off running qmlRegisterType inside your KgDeclarativeView if you were doing it this way.

I'm not sure if I understand the first point.

qmlRegisterType would only register a type with the declarative engine. I want to be able to access this particular instance of the KGameRenderer. Besides, the renderer object is not meant to be used from the QML, it is only for the c++ qml components in case they need it, so qmlRegisterType is not really required, though can be done.


- Viranch


-----------------------------------------------------------
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/20120811/c7e4a956/attachment-0001.html>