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

[David Edmundson]

> 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.
> 
> Viranch Mehta wrote:
>     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?

Good point.


> 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.
> 
> Viranch Mehta wrote:
>     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.

I'll try again.

The whole point of having a QML library is so that I can run
"import org.kde.games.core 0.1" and it will _just work_.

This isn't the case. It only works if you have already some certain rootContextProperties defined, at which point it isn't right for it to be a standalone plugin. Someone else who tries to use your plugin (without magically knowing this) will find it not working, or worse crashing. It works now for your code, but for it to be in a library, we need to make sure it's hard for people to "use incorrectly".

If the only way to use a CanvasItem is through a KgDeclarativeView. Then we should just called engine()->qmlRegisterType(CanvasItem...) in the constructor of KgDeclarativeView.


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

Then it's KGameRenderer that needs to be a singleton, not a static pointer in the classes using it.


- David


-----------------------------------------------------------
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/7b88ecbe/attachment.html>