[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