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

[Marco Martin]

On Monday 16 August 2010, Stefan Majewsky wrote:
> Hi,
> 
> because some people on plasma-devel@ might not know me yet: I'm a member of
> the kdegames team, and am posting to plasma-devel@ for the first time
> because my work may have to do with what you folks are doing. (This
> implies that I'm not subscribed her, so please CC me or kde-games-devel@
> in answers.)
> 
> The reason why I'm writing this is because I started work on libkgame, a
> collection of libraries which shall, at some point, supersede libkdegames
> which is currently used by most games in the kdegames module. In the
> beginnings of the design process, I've identified as a main weakness of our
> applications the fact that they are designed for mouse and keyboard
> interaction and for desktop form factors. They do not scale to the mobile
> form-factors which are becoming increasingly important in casual gaming.

I hope this would succeed, a touch friendly version of kdegames would be an 
excellent showcase of kde-mobile (and possibly with less rewriting effort 
compred to some other category of applications)

> Most of our games are QGraphicsView-based, and I know that the Plasma
> community is the home of some of the greatest QGraphicsView experts on our
> lovely planet. Plus, many of you have experience in interface design on
> constrained devices.

i must say some of the (simpler) games, like KPat are already quite usable 
from a touchscreen, maybe you're not so far from the target.
one important thing would be some way to replace all the "chrome" around the 
game with something more mobile friendly (they usually have a menubar, 
traditional config dialogs etc)

> I would like to invite you to thinking about, discussing and designing a
> general set of interface components for games which can be used on mobile
> devices instead of the usual WIMP controls. The ultimate goal is a UI
> system which allows the game developer to develop in one working step an
> interface that works both on the desktop and on mobile devices. Think
> XMLGUI on steroids.

hmm, this looks a bit like qml to me.
and yes i'm aware and agree on the concerns over its architecture, but perhaps 
it should not be discarded before evaluating if it could have some 
applications there

> This effort should also cover input methods, in order
> to make it dead-easy to integrate multitouch support in existing
> applications.

for input, basically if you are chained to single touch, mouse events are 
usually mostly good enough, if you want to react to multi touch you should 
implement -also- TouchEvents, that have a semantics almost identical to mouse 
events, apart that they have an arbitrary number of points in a single event.
there are also higher level gestures, but are probably -too- high level to be 
used in games...

> 
> Of course, this need not be limited to games, but could be generalized to
> arbitrary applications. I doubt, however, that this is possible because
> games with their full-screen application-styled canvases have their own
> distinct requirements.

yes, i can see it largely game-specific.

> Not only am I interested in your thoughts on how such interfaces (or
> library classes) might look like, I'd also like to know whether there are
> existing components which might be reused. From what I know about Plasma
> (and that's admittedly not as much as I would like), Plasma is too
> high-level for what I need. It's not about creating applets for different
> services, but about arranging buttons and score displays. But please,
> correct me if I'm wrong.

yes and no.
there are some components however that could be of some use:
widgets:
generic widgets like pushbuttons, sliders, flickable scroll widgets: those 
things could be pretty good to score displays, config interfaces etc.

dataengines/services: if at some point you want to implement some kind of 
online leaderboard, to upload/download high scores they could be rather useful

paint rutines: we have a quite efficient svg loading and painting mechanism 
with on disk cache of the rasterized stuff that seems to scale pretty well on 
not-so-capable devies (when there aren't cache misses it is possible to 
display svgs without instantiating any svg parser)

as for the applet/containment architecture, yes i don't see an use yet.. 
(apart for a separate plasmoid that would update you about the said online 
leader board of  particular kde game, but this is another topic)

Cheers,
Marco Martin