Base classes declaration under DUChains

[Lior Mualem]

>
> Hrm, patch was empty in my mail client.
>

I'll just inline it in the mail - it's a one liner:

Index: classmodel.cpp
===================================================================
--- classmodel.cpp    (revision 939163)
+++ classmodel.cpp    (working copy)
@@ -397,7 +397,7 @@

   for(uint a = 0; a < itemCount; ++a) {
     // Don't insert unknown or forward declarations into the class browser
-    if (items[a].kind == CodeModelItem::Unknown || items[a].kind ==
CodeModelItem::ForwardDeclaration)
+    if ( (items[a].kind & CodeModelItem::Unknown) || (items[a].kind &
CodeModelItem::ForwardDeclaration) )
       continue;




>
> > And with regards to what you're doing there, are you fixing the class
> > browser yourself? I don't want to do redundant work in that area.
>
> I have made it a bit more reliable (updates properly), but haven't tested
> it
> very well.  A good project to help understand qt model/view would be to get
> the search line working.
>

I'm thinking of using a proxy model to filter out the nodes, it could be a
good practice but I need to see if that's even possible.


>
> > I was thinking of doing a whole refactoring of the code there - one of 2
> > things (I must say first that these ideas came up before I've updated the
> > code to reflect your new changes so maybe you've done something in the
> > directions I list here):
> >
> >  1. Drop the whole model / view architecture currently used there, our
> > "model" concept is actually the DUChains. Instead of doing another model
> > class which translates and caches many information from the DUChains to
> the
> > QT model design, I'll simply modify the "view" (The QTreeView in our
> case)
> > to fit our model existing model (the DUChains). So far, from what I've
> > seen, the model concept is deeply used within QT and changing the model
> > concept used there is abit askew.
>
> The class model is a wrapper between duchain and qt's model/view
> architecture.
> The basic structure has to be duplicated due to multi-threading (model/view
> can't accept non-gui thread additions/removals, etc) and other
> considerations
> (this is why we need our own nodes).
>

That's true but storing our own nodes make it more memory inefficient over
time - when you expand the node, you generate the sub-items (functions /
members / base classes / etc.) and then you'll have to monitor it for
changes and update it and if the user collapsed it, I don't think we have a
clean way of knowing that in the model to stop the monitoring and cleanup
the used memory.
I know about myself that when I browse the classes, I collapse the ones that
I don't examine at the moment to reduce the clutter.

That's why I've been thinking of that direction, the Widget itself has the
knowledge of what's visible at the moment so to the very least, I'd want to
handle the collapsed signal from the widget in a model / view manner
(meaning maybe create a widget and a model which better suits the class
browser concept and not use directly the ones already provided by Qt).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090314/290fd665/attachment.html>