Base classes declaration under DUChains

[Hamish Rodda]

On Saturday 14 March 2009 13:33:31 Lior Mualem wrote:
> On Sat, Mar 14, 2009 at 12:29 AM, Hamish Rodda <rodda at kde.org> wrote:
> > On Saturday 14 March 2009 08:05:23 David Nolden wrote:
> > > I think we were thinking about moving Cpp::ClassDeclaration to
> > > kdevplatform, but haven't come to it yet.
> >
> > That would be good, i had to duplicate much of it for java.
>
> Should I just try to move it my self or are there any objections? It'll
> help me get the hang of the code and eventually it will save me the trouble
> of going through the imported contexts (it'll probably be good also for the
> java code).

I'd be ok with that, see what David thinks.

> > > So how far have you come with the class-browser? At some point I might
> >
> > peek
> >
> > > at what you've done. The most important thing is that it should be
> > > fast. You should remember that whenever you call
> > > KDevelop::IndexedDeclaration::declaration(), it may mean a complete
> > > file has to be loaded from disk. For that reason, the actual duchain
> > > declarations or contexts should only be used for displaying detailed
> > > information that is actually visible on the screen. All other content
> > > of the class-browser should use the simple representation from
> > > KDevelop::CodeModel(It is maybe a bit too simple, but with some tricks,
> >
> > it
> >
> > > can be used to build a hierarchy)
>
> When I'll have something, I'll be happy to share it with you for review. So
> far I'm still trying to learn the code - I have 3 new APIs to learn around
> here - KDE, QT and KDevelop. Specifically, I had to understand if the
> Model/View that QT uses and the current class browser code uses fits the
> requirements and I've been toying around with the kind of information I can
> extract from the DUChains and that I want to display (such as base
> classes). I'll keep that in mind when I decide what information to display.
> But my rule of the thumb is not to load anything unless the node is
> expanded. My second thought was when to "unload" the information from the
> tree view which leads me to the 2 choices I write about below.
>
> > I fixed the code browser a few days ago, it works pretty well now except
> > that
> > for some reason the forward declarations are still displayed even though
> > I've
> > filtered out any CodeModel::ForwardDeclarations.
>
> On that note, I actually found this bug while playing with the existing
> code - under the function ClassModel::refreshNodes:
> The item kind is actually a bitset so instead of equality check, you should
> perform bitwise check. I've attached a patch for you to look at.
> Isn't there a better way to represent bitwise enum with QT classes instead
> of using an int to hold the values? (for the item kind)

Hrm, patch was empty in my mail client.

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

>  2. Change the node implementation in the ClassModel to have derived
> classes to represent the different kind of nodes (namespace, class,
> function, etc...) and move the expansion and context menu and icons and
> basically the whole logic to the specific nodes implementation. The reason
> for this is mostly because I want to have the base classes as a tree item
> within the class node so having the logic behind the type of the node
> reside in a specific class will make the lazy loading more easily
> implemented when the expansion is recursive (expand the base class item
> within the class item and again for that base class and his base classes,
> and so on and so on).

This can be done from the main model code if you like too, but either way 
would suffice.

Cheers,
Hamish.