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

[Viranch Mehta]

> 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.
> 
> David Edmundson wrote:
>     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.
>     
>

Well theoretically, the CanvasItem component can be used only after being supplied with a KGameRenderer, which it picks up on its own via the "renderer" rootContextProperty. So it is kind of expected from developers to explicitly set that rootContextProperty. But since this might not the best way to do it (or might be unintuitive), we could make the CanvasItem available only through KgDeclarativeView as you said.

An alternative we could probably go for is this, we have KGameRenderer instantiated from inside the QML plugin which sets it in the declarative engine's rootContextProperty, and make it available to the game by KgDeclarativeView. So whoever uses the plugin has a "ready made" renderer accessible. I'm yet to ensure that this would work though.


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