[Kde-games-devel] Re: KDE games strategy

[Aaron J. Seigo]

On Friday, July 29, 2011 10:49:57 Stefan Majewsky wrote:
> I'm not sure if there is value in porting the existingQGraphicsView-based
> canvas logic to QML.

if it isn't broken, don't fix it. :)

for new games, it could well make sense to start out with QML, however. or if 
one of the existing games gets a UI rewrite, it could also make sense. but for 
existing games ... nah. they work, and that's important.

it's really the chrome that's the issue, as you note next:

> For the chrome, we probablyneed something QML-based,
> but I don't see how work on this topic inthe Qt/KDE 4 timeframe won't get
> obsoleted by developments in Qt 5. This is also the reason why I'm trying to

well, the replacements do not need to be done in QML, per se. they could be 
done with plain old QGraphicsItems/Widgets ... the chrome could be done in QML 
(which lives in QGV just fine), and if kept simple enough shouldn't run into 
many (any?) issues in Qt5. the big changes right now are in how to bind 
objects from C++ into the QML, the option to have a GL scenegraph instead of 
QGV and lots of internal changes. but even if this is a concern, there's no 
reason the chrome couldn't be replaced with things in-window on the 
QGraphicsScene.

.. and one may wish to rethink some of the smaller current design choices. 
e.g. in lskat, the menu must be used to start a game unles you show the 
toolbar which takes up a bunch of room for two items. there could be a mouse 
area right in the intro screen that lets you start a game .. or a game could 
even automaticall be started.

"End Game" could appear between the two card decks.

a settings menu system that operates full-window and in-window could be 
produced that turns a set of QActions into options on screen, just as QMenu 
does.

and then the menu bar, toolbar and status bar could all go away .. problem 
solved :)

is that something that the games maintainers might be willing to accept 
patches for?

> the highscore dialog: Can you explain how one could improve that?

my suggestion would be this: put it in-window (as opposed to a separate dialog 
window), and theme it like the rest of the game. that could even be done with 
QML (without touching anything else in the game)

> P.S. BTW, are there stated hardware requirements for Plasma Active?

we currently actively test with these devices:

	http://community.kde.org/Plasma/Active/Device

we will expand that list in the future. however, a specific hardware spec is 
not defined and for good reason: Plasma Active is looking at the device 
spectrum, not simply tablets.

Contour is designed with touch in mind, and some of the apps do indeed have 
multitouch features (for instance) but we do wish to take the base of Plasma 
Active to other types of devices that are fairly different, e.g. perhaps set 
top boxes.

the default UI bits will be arranged differently on those devices (as they are 
already for Desktop, Netbook, Tablet and Mobile) but the foundation is the 
same and UI sharing is paramount.

> For example, can I rely on multitouch being available?

no.

-- 
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/20110729/f8b07e4d/attachment.sig