On Sunday 04 July 2010 00:01:46 Parker Coates wrote:
> Does that mean that KGameRenderedItem no longer has a setOffset()
> method? I use that in Killbots.

I'll add one.

> I'm also concerned with the potential runtime cost of doubling the
> number of items in the scene. Would you mind elaborating on why you
> felt the need to switch to QGraphicsObject? My understanding was that
> it was only a convenience class for handling the QObject::parent()
> QGraphicsItem::parent() conflict and the Q_INTERFACE.

There is no conflict between the parent() methods because it's 
QGraphicsItem::parentItem() for exactly this reason. (Also, the APIDOX 
suggests to use QGraphicsItem::setParentItem and NOT QObject::setParent to 
model QGraphicsObject hierarchies.)

Then QGraphicsObject provides the properties, change signals, quick casting. I 
could copy all of this into KGRI, but sharing the implementation is especially 
good for future-proofness. If, say, Qt 4.8 brings a new feature in 
QGraphicsObject which is desperately needed by us, then I have no chance to 
use it if KGRI is QObject/QGraphicsPixmapItem-derived. With the 
QGraphicsObject superclass, I can stuff anything I like into KGRI internally.

On the runtime cost: It should not be much. Graphics View is designed to 
handle thousands of items (see the "chip" demo which comes with Qt) without 
producing much overhead. Perhaps someone of the Qt devs reading k-d@ could 
coment on that?

Apart from all that, moving the QGraphicsPixmapItem into the KGameRenderedItem 
internals allows me to play with its coordinate system in interesting ways. 
The addition of the primaryView property and the associated fixation of the 
coordinate system actually were totally necessary to enable porting of Kolf 
(which I'm working on currently).

Greetings
Stefan
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<