[Kst] branches/work/kst/kst1kde4/kst/src/libkst

Barth Netterfield netterfield at astro.utoronto.ca
Fri Nov 20 19:39:54 CET 2009


Yes: I might have to pull the updating stuff out so viewitems can get at it, 
in which case, Kst:Object  will just be a class that just enforces uniform 
inheritance in a convenient way.

Looking at my brached version of besides updating stuff,  there is:
	deleteDependents: an interesting one - 2 schools of thought:
		either, we can delete any object at any time, 
		and this method deletes everything that depends on it
		or: we can only delete things that are otherwise not 
		used (the kst 1.x way) and this method goes away
	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
	Shared: would go away if we use QSharedPointers
	QObject: signals, slots, and much much more - keep it.


So... at the end of the day, I think we still want Kst::Object, but it may 
become a lot thinner.

cbn

On Friday 20 November 2009 13:14:21 Peter Kümmel wrote:
> What about splitting out the update functionality in a new class,
> eg. 'Updatable'?
> 
> Peter
> 
> Barth Netterfield wrote:
> > Actually, I am in the midst of a major update system redesign.
> >
> > Kst::Object provides the interface for a number of general things related
> > to updates.
> >
> > cbn
> >
> > On Friday 20 November 2009 12:20:52 Peter Kümmel wrote:
> >> Now I realize, sharedptr.h is only to implement a thread save smart
> >>  pointer, with the disadvantage that a class which SharedPtr points to
> >> must inherit from Shared. So sharedptr.h could be completely replaced by
> >> QSharedPointer.
> >>
> >> I also have the impression often the only feature used from Object is
> >> the memory management, so I wonder if we couldn't remove inheritance of
> >> Object at several classes, because QSharedPointer works with any class.
> >>
> >> Peter
> >>
> >> Barth Netterfield wrote:
> >>> http://labs.trolltech.com/blogs/2009/08/25/count-with-me-how-many-smart
> >>>- pointer-classes-does-qt-have/
> >>>
> >>> I *think* we are OK with QSharedPointer for Kst::Object as long as we
> >>> make sure that every Kst::Object that gets created is only pointed to
> >>> by a QSharedPointer (and never a normal pointer). And this is good
> >>> policy anyway.
> >>>
> >>> In this case, we would never call delete on a Kst::Object -
> >>> QSharedPointer takes care of that for us.
> >>>
> >>> The QExplicitlySharedPtr class is used for sharing data, not pointers. 
> >>> I don't see any use case for copy-on-write for Kst::Object (in fact,
> >>> copy contstuctors aren't even defined).  So in principle, they would
> >>> work - but I think at this point we will be much happier with
> >>> QSharedPointers, as long as we follow the simple rule: No Kst::Object
> >>> *s anywhere!
> >>>
> >>> This won't work for Kst::ViewItem, unfortunately, since these are all
> >>> held by the QGraphicsItem class as plain pointers... so, no smart
> >>> pointers for Kst::ViewItems at this point.
> >>>
> >>> cbn
> >>>
> >>> On Thursday 19 November 2009 12:49:12 Peter Kümmel wrote:
> >>>> Barth Netterfield wrote:
> >>>>> On November 19, 2009 11:43:27 am Peter Kümmel wrote:
> >>>>>> do we need the 'Explicitly' version?
> >>>>>
> >>>>> Explicitly shared objects inherit from a class which keeps track of
> >>>>> their usage counts internally.  With QShared, the pointer itself
> >>>>> keeps tack of usage - which is harder to manage.
> >>>>>
> >>>>> cbn
> >>>>
> >>>> I know the Qt's classes where QSharedData is used to implement
> >>>> shared data classes.
> >>>> Implicit or "copy on write" classes, like most of Qt's classes, use
> >>>> QSharedDataPointer internally, classes which do not support "copy
> >>>> on write" and
> >>>> where you have to detach manually (explicit) uses
> >>>> QExplicitlySharedDataPointer internally:
> >>>> http://doc.qt.nokia.com/4.6-snapshot/qshareddata.html
> >>>>
> >>>> For reference counting there is QSharedPointer.
> >>>>
> >>>> We should map kst's classes to Qt's classes, and therefore the
> >>>> question:
> >>>> Do we need shared data objects where we have to call detach() or
> >>>> is "copy on write"
> >>>> enough. "copy on write" is less error prone because you could not
> >>>> forget to call
> >>>> detach.
> >>>>
> >>>> Peter
> >>>> _______________________________________________
> >>>> Kst mailing list
> >>>> Kst at kde.org
> >>>> https://mail.kde.org/mailman/listinfo/kst
> >>>
> >>> _______________________________________________
> >>> Kst mailing list
> >>> Kst at kde.org
> >>> https://mail.kde.org/mailman/listinfo/kst
> >>
> >> _______________________________________________
> >> Kst mailing list
> >> Kst at kde.org
> >> https://mail.kde.org/mailman/listinfo/kst
> >
> > _______________________________________________
> > Kst mailing list
> > Kst at kde.org
> > https://mail.kde.org/mailman/listinfo/kst
> 
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
> 


More information about the Kst mailing list