Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries
Marco Martin
notmart at gmail.com
Tue Aug 17 13:21:15 CEST 2010
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
More information about the Plasma-devel
mailing list