syntheticpp at gmx.net
Fri Nov 27 00:26:39 CET 2009
> This is a user preference question: do I want to be able to delete a vector
> and everything it depends on from the data manager, or do I have to start
> the top of the tree, eg, remove the curve from the plot, delete the
> then delete the vector... 1.x had a 'purge' button which would repeatedly
> delete all unused object until everthing that was unused was gone to make this
> more convenient. That being said, I tend to agree we should go back to the 1.x way.
I don't know the data manager. Is it like a vector paint program? Then why not simply delete only marked objects?
> > > getUsage(): would go away if we use QSharedPointers.
> > >
> > > and it inherits
> > > NamedObject: needed for everything. It is in a separate class
> > > so viewitems can also get at it
> > > KstRWLock: for locking. Don't know its history
> > I assume we could find a Qt replacement for KstRWLock and we don't
> > need to inherit from that Qt class.
> QReadWriteLock looks like a likely candidate.
> > > QObject: signals, slots, and much much more - keep it.
> > when needed ...
> I think most, if not all Objects need these things.
> > > So... at the end of the day, I think we still want Kst::Object, but it
> > > may become a lot thinner.
> > The questions remains, for what do we need Object then?
> -Uniform/easy inheritance.
> -So we can have a common list of all objects for updates, etc.
> Otherwise, we *could* break up into list of dataSources, list of
> list of dataobjects, and list of relations. Would probably speed up some
> things, but might add some code.
> I can imagine that ViewItems might become objects as well... would be nice
> Kst mailing list
> Kst at kde.org
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
More information about the Kst