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

Kleag kleag at free.fr
Fri Nov 21 00:37:52 CET 2008


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 also don't need to separate the QGraphicsItem and the QObject (you're
> just asking for syncronization overhead); you can multiple inherit QGI and
> QObject and apply the same design strategy that was suggested. (or use
> QGraphicsWidget if that's more your game, which MI's QObject and
> QGraphicsLayoutItem, though QGW probably doesn't make much sense for a game
> like kolf)
>
> a situation where i could see using separate QObject's is if the data
> contained in them is complex/expensive and can be shared across multiple
> QGI's, like a style object a layout document.
>
> but if each object's data is both simple and likely to be unique anyways, i
> would personally skip the complication of separate QGI and QObject objects.
>
> > I agree for the config solution, though.
>
> yes, that seems solid.
>
> > 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. Again, this could be done also 
without separating the QObject from the QGI and then communicate with the 
widget. I was talking about general principles, thus writing very general 
statements. 

And I should also add that I'm really not a GUI guru. So, if I'm wrong I'll be 
happy to (try to) learn :-)

Gaël

-- 
KsirK - a world domination strategy game 
http://techbase.kde.org/Projects/Games/Tactic_and_Strategy/KsirK

KGraphViewer - a GraphViz dot graphs viewer
http://extragear.kde.org/apps/kgraphviewer



More information about the kde-games-devel mailing list