Please remove all uses of KDevShared and KDevSharedPtr

[Matt Rogers]

On Friday 25 August 2006 07:35, Hamish Rodda wrote:
> 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... :)

If we have to use a shared pointer we should switch to the KDE 4 version, but 
we shouldn't have to use them that often and perhaps by having to go through 
the trouble of switching, people will just do real memory management ( at 
least this was my thinking )

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

I was already going to take care of this

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

Well, the problem with the KDevItem stuff is that it tries to be too generic 
and fit every single possible way a model might be used in kdevelop, for 
which we should just create individual models for that, IMHO.
-- 
Matt