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

[Aaron J. Seigo]

On Sunday, August 22, 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.

Marco already answered this a bit, but let me go into more detail:

Plasma::Theme represents a collection of 1 or more SVG documents; it 
simplifies asking for "the svg file named foo". you set the theme to use 
globally, and everything that asks for "the svg file named foo" gets the right 
one. this is obviously saves less work for an app that uses only one svg file 
versus several, but it does nicely abstract away the idea of "different 
themes", which is indeed something that the KDE games support.

i'd also note that there is a limit to the performance to be gained from 
having just one big SVG file, and you are sometimes better off splitting 
things up, depending on the number and complexity of the elements.

there's also the issue of consistency between the games; if there were 
sharable SVG elements, it would be nice to use a more comprehensive theming 
system that allowed layering of partial (game specific) theme files over / 
along side global SVG files, thereby allowing those global files to be used by 
all the KDE games. i don't know if there are any such opportunities for re-
use, and if not, then there's no point to this.

the one other thing that Theme provides Plasma is a convenient place to keep 
the central caching of rendered pixmaps for all Svg objects (or other items 
needing some sort of extra-scene caching). this placement is more a matter of 
convenience, however, rather than a requirement.

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

there are, as Marco noted, two classes: Plasma::Svg and Plasma::FrameSvg. 
FrameSvg adds the idea of a "box" made up of 9 different elements and the 
ability to have elements for different edges of the UI (allowing, e.g. for 
lighting hints to be different for one drawn on the right versus the bottom of 
the window/screen/view).

Svg itself allows one to access individual elements. in fact, this is the most 
common method of usage. the elements can be connected to a Plasma::SvgWidget 
which can then update automatically when the Svg does.

one could add a non-painting object like KGameRendererClient that does what 
SvgWidget does (minus the painting :) in under 20 lines of code. the only 
benefit i can think of in doing that would be to create objects that represent 
a given element and handing them to a painting object so that the painting 
object doesn't need to know the name of the element it is painting; besides 
improved encapsulation in that pattern, this could be useful in the case where 
the element object is passed around between painting objects over time, 
allowing the details of "which Svg element id and which Svg" to be ignored.

> * While Plasma renders (AFAIK) nearly its complete UI from these themes,
> games consist of a relatively small number of sprites.

no, Plasma renders portions of its UI from various elements in various Svgs. 
some of these portions take the form of QGraphicsProxyWidgets that have nice 
theming, other portions are simply drawn from the Svg elements (the analog 
clock and the new monochrome system tray widgets, as two different kinds of 
examples), and all of those bits are then put together in the scene.

there's actually far less difference than one might expect between, say, the 
average panel in Plasma Desktop and a KDE game in this respect :)

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

QML doesn't magically give you themed widgets. you still have to provide them. 
libplasma does exactly that for you.

> > it's also possible to write games as plasmoids and run them in a window.
> > bonus is that we'd get the ability to house all games in a plasma shell,
> > which could be nice on mobile/touch devices for integration purposes. for
> > games that are already QGraphicsView based, this should be relatively
> > trivial. for others, it could be a lot of work.
> 
> Most of our games are QGV-based (a current dataset is at [2]), but quite
> some of them do funny things with the view to implement the scaled
> contents. This makes it at least non-trivial to port them to a view-less
> environment like a plasmoid.

yes and no.

if the assumption is that they own the view, then yes, it isn't going to be 
readily possible to run such a game in a view with other items in it.

even with that assumption, though, they could be written as plasmoids and run 
with their own view.

the benefit of that is it becomes easy to use these games on a system already 
running plasma (e.g. via plasma-windowed) and you get all the fun stuff in 
available to a plasmoid in libplasma. notification of rotation from horizontal 
to vertical, for example.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20100823/09696dc3/attachment-0001.sig