[Kde-games-devel] Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries

[Marco Martin]

On Sunday 22 August 2010, Stefan Majewsky wrote:

> Interestingly, I have just now written kdegames' own SVG rendering,
> painting and caching system, with all bells and whistles. (Ask api.kde.org
> for KGameRenderer.) The use case is different:
> * Plasma uses a theme composed of multiple SVG files, AFAIK to be able to
> fallback to the default theme when some of these SVG aren't available. OTOH
> our games use a single SVG theme which contains all visual components.
> * Plasma::Svg seems to be the lowest granularity of theme components.
> KGameRenderer has the KGameRendererClient which is attached to a single SVG
> element, and receives a new pixmap automatically, should the need arise.
> * While Plasma renders (AFAIK) nearly its complete UI from these themes,

so, a brief explanation is due:
Plasma draws its ui elements with a class called FrameSvg, that is a Svg 
subclass and composes the 9 elements needed to render something like a rounded 
button-ish look.
Svg is a class that opens an svg file and can draw it either complete or a 
single element of it, so having the whole graphics needed for a game in a 
single file is perfectly possible.

> games consist of a relatively small number of sprites. Progress bars etc.
> are (if at all) simple QWidgets. Of course, if we want to move everything
> into the themed game view, we will have to theme these elements, but I
> think that QML is a much more likely candidate there.

you will need some wrapper class to use svg from qml then bind for it, because 
there is nothing for svg

Cheers, 
Marco Martin