[Kde-games-devel] Kolf rewrite (includes important design question even for non-coders)

Aaron J. Seigo aseigo at kde.org
Fri Nov 21 02:04:15 CET 2008


On Thursday 20 November 2008, Kleag wrote:
> Le Friday 21 November 2008 00:00:27 Aaron J. Seigo, vous avez écrit :
> > On Thursday 20 November 2008, Kleag wrote:
> > > Having separate classes for view (QGraphicsItem) and model  (QObject)
> > > seems
> >
> > technically, QGraphicsItems are not view but model objects on the
> > QGraphicsScene, which is itself a model which the View visualizes.
>
> Well, I'm maybe wrong but I see QGI as a view of a data object because it
> is doing the painting operations. Effectively, QGraphics is not a pure
> Model- View-Controler like in Smalltalk and it is maybe too much overhead
> to separate data and painting in the case of kolf but without having looked
> at details I was giving my general opinion. So, you can be right in what
> you wrote below.

you're right that it isn't MVC at all. it's scene/view based which is more  
typical for graphics applications.

however, while the items provide the painting, they do so with just a 
QPainter, a QStyleOption, and a QWidget pointer that is the specific view it is 
painting to.

it's sort of the graphics version of M/V.

the QGIs represent the objects that will get painted: the geometry, the 
trasnform and other relevant data. the scene also does calculations for things 
such as collisions, stacking orders, etc. none of that requires a View.

the View then specifies how it would like to show them. with View subclasses 
you could even couple your items to specific types of views, so the same items 
could paint to an overview map in the top corner (which would be one 
QGraphicsView) and a "1:1 zoom" view in the rest of the window (which would be 
another QGraphicsView). same scene, same items, different painting in both but 
no need to "sync" up the map with the view: they are both painted from the 
same set of items in the scene =)

> > > have more than one view of the same object, e.g. two perspectives.
> >
> > i assume you aren't talking about multiple views on screen, but multiple
> > views inside from a code design perspective?
>
> No, I am talking of multiple views inside: for example a QGI in the scene
> and a text description in a standard widget.

ah, sure, yes, this could be done either way.

or you could even have a "proper" QAbstractModel and map that to both a 
QGraphicsScene (with a bunch of code =) as well as use it as normal.

simplicity suffers though =)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-games-devel/attachments/20081120/7db9dc15/attachment-0001.sig 


More information about the kde-games-devel mailing list