how to manage QGraphicsScene
Maximilian Kossick
mkossick at gmx.de
Sat Jul 21 09:23:26 CEST 2007
On Friday 20 July 2007, Ian Monroe wrote:
> So currently PlaylistNS::Model just has a Meta::TrackList of tracks,
> which it inserts, removes etc. directly. This is neat because when you
> drag stuff from the collection browser it can insert stuff directly
> into the TrackList at essentially no cost.
>
> But I'm needing to add some playlist specific data to the Tracks or
> otherwise associate the data with them. The issue is that currently
> the Delegate creates QGraphicScene's, adds shit to them, paints them
> and then destroys the QGraphicsScene. This is a bit wasteful and is
> also why I think editing the text currently doesn't work even when I
> set it to on (hopefully it doesn't rely on a QGraphicsView...).
>
> So I could...
> *Subclass Meta::Track, make a PlaylistNS::Item, with a new ->scene()
> method that makes a new scene if there isn't one already or just
> returns the existing one. But I don't think I could morph a bunch of
> Meta::TrackPtr's into this new object (unless we start using Ruby).
> *Have PlaylistNS::Item not derive from anything, just have it with a
> Meta::TrackPtr data member and a QGraphicsScene member. Then keep a
> list of this.
> *Have a new specialized list type which keeps in sync two separate
> QLists of QGraphicsScenes and Meta::TrackPtr's.
>
> I'm leaning towards the last solution, but I was wondering if anyon
> had another idea.
>
> Ian
Option two sounds like the least work two me. Keeping the members private and
creating the qgraphicsscene on first access should keep both memory
comsumption and complexity (because you don't have to check for null-pointers
in the calling code) down.
Cheers, Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070721/a904af4d/attachment.pgp
More information about the Amarok-devel
mailing list