Base classes declaration under DUChains

Hamish Rodda rodda at kde.org
Sat Mar 14 02:46:46 UTC 2009


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.




More information about the KDevelop-devel mailing list