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

[Peter Kümmel]

Barth Netterfield wrote:
> 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

Isn't the way "we can only delete things that are otherwise not used"
much better than "can delete any object at any time"? Because who knows
the right time?

> 	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.

> 	Shared: would go away if we use QSharedPointers
yes
> 	QObject: signals, slots, and much much more - keep it.

when needed ...

> 
> 
> 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?

Peter


> 
> 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
>>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>