[Kst] Architectural changes

[Peter Kümmel]

Am Donnerstag, den 10.12.2009, 10:16 -0500 schrieb Barth Netterfield:
> After going through in detail the use of <Object>Ptrs in kst last week, I 
> found and removed a couple places that were causing some our memory leaks and 
> crashes, or at least causing KstSharedPtr to not delete things when it should 
> (and to delete things when it shouldn't). 
> 
> The Store is basically a list, with a couple convenience functions thrown in 
> (template functions to create and find objects).  I think that this is how it 
> should probably stay.

Yes, it seems essential to the current design.

> 
> Kst uses KstSharedPtr, which does in fact seem to work just fine.  I don't 
> think we should change that either.
> 	(Note: KstSharedPtr has the huge advantage over a QSharedPtr that it stores 
> its reference count in the object itself, so a KstSharedPtr can be converted 
> into a bare pointer, passed somewhere, and converted back into a KstSharedPtr, 
> and the reference count is happily carried over.  Not so for QSharedPtr, which 
> holds the reference count in the pointer itself.)

Having access to the reference count completely breaks the idea of
shared pointers, so I would say such must NOT happen, and if access
is needed, then there is a bug in the design. 

It also makes the code more readable if one don't need to learn
some strange smart pointer behavior.

Therefore I would still replace KstSharedPtr, even when it is more
complicated at some places. If we leave KstSharedPtr it will bite
us later.

> 
> The last big 'under-the-hood' work is related to locking.  Currently, we are 
> not multi-threaded, except for some stuff related to data-source 
> initialization, so any locking troubles we might have, we don't currently 
> face.  This will need to be fixed.  I propose we delay this until after 2.0.
> 
> So:  From now to 2.0, we should work only on critical bug fixes and critical 
> or very easy feature fixes, which a goal of a 2.0 release on the weekend of 
> January 1.
> 
> The exception to this would be if we find a reason we would need to do an API 
> change to data-sources or plugins, in which case the Jan 1 release would be 
> called '2.0-beta4'
> 
> Thoughts?
> 
> cbn
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst