Please remove all uses of KDevShared and KDevSharedPtr

[Hamish Rodda]

On Friday 25 August 2006 22:16, Matt Rogers wrote:
> On Friday 25 August 2006 01:54, Hamish Rodda wrote:
> > On Friday 25 August 2006 13:41, Matt Rogers wrote:
> > > Hi,
> > >
> > > I'd like to remove KDevShared as soon as possible since it's nothing
> > > more than a copy of the KDE 3 version of KSharedPtr. Please read about
> > > the new KDE 4 version of KSharedPtr and start switching anything that
> > > is using KDevSharedPtr to KSharedPtr. So far, this is only used in the
> > > project model stuff and in the parsers. Once the parsers are done, I'll
> > > be removing KDevSharedPtr.
> >
> > I looked at this a while back.  The problem is that the kde4 shared
> > pointer does have an important difference - it does not easily allow the
> > pointer to be returned; only dereferenced, compared, etc.  Thus,
> > converting much of the code model stuff was very difficult, and to me not
> > worth the effort.
> >
> > However, there is a deeper point to be made here - these use of shared
> > pointers in the code model (and probably other places) are really a
> > cop-out to appropriate memory management.  With the new binder that I'm
> > about to create for c++ (I had a few conceptual breakthroughs on my bike
> > ride today that I'm pretty excited about), they will not be required. 
> > So, if I can succeed here, we can change other uses over to the kde4
> > version.
>
> That was kind of the idea behind the removal. Force people to do proper
> memory management rather than rely on shared pointers :)

I thought you just wanted to switch to the kde4 version... :)

> > In addition, I propose porting all of the KDevItem* stuff over to
> > QStandardItemModel.  We have an extra layer of complexity which isn't
> > helping us, and this model should take care of many details for us.
>
> The KDevItem* stuff is already a QAbstractItemModel and I'm not sure we
> gain anything by converting to the QStandardItemModel. (based on the
> current code) However, I'm working on simplifying it and so I'll take a
> look at this as well.

Ah...:
1) Maintainability
2) Removal of confusion about KDevItem Collection / Group distinction
3) Automatic emitting of model change signals
4) Ability to delete our QAbstractItemModel subclass
5) I think it even has serialization support (but I can't see it right now)

To me, the QAbstractItemModel approach is really for when you have data in a 
different format than a 1:1 conversion to what you want to present.

Cheers,
Hamish.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20060825/b1338935/attachment.sig>