Base classes declaration under DUChains

[Lior Mualem]

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:
> > Am Freitag 13 März 2009 21:46:03 schrieb Lior Mualem:
> > > Hi,
> > > I'm trying to display a list of base classes within the class browser
> and
> > > I see that the base classes list is Cpp specific - in
> > > Cpp::ClassDeclaration thus it exists only within the KDevelop project
> and
> > > not under the kdevplatform project (which is where the class browser
> > > should be).
> >
> > There is a slight duplication in this regard. You can also get to the
> base
> > classes through the context structure:
> > Declaration* declaration = Declaration of a class
> > foreach(DUContext::Import import, declaration->internalContext()-
> >
> > >importedParentContext())
> >
> >  if(import.context()->kind() == DUContext::Class)
> >       then import.context()->owner() is the declaration of a base-class
> of
> > declaration
> >
> > Notice that you always have to do a null-pointer check, for all the
> > pointers treated in that code.
> >
> > > Is there a reason why a list of base classes shouldn't reside within
> > > something that's defined in kdevplatform (atleast an interface class)?
> >
> > 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).


>
> <snip>
>
> > > P.S: Is there developer documentation that explains the idea behind the
> > > different classes and their relations with regards to DUChains?
> >
> > I think Hamish Rodda has written some documentation, I don't know where
> it
> > can be found though.
>
> http://api.kde.org/4.x-api/kdevplatform-
> apidocs/language/duchain/html/index.html<http://api.kde.org/4.x-api/kdevplatform-%0Aapidocs/language/duchain/html/index.html>
>

Thanks, I'll have a look at it later.


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


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

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

I hope I got my ideas over, It's a little bit late here now ;)
Lior
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090314/98ea1540/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itemtest.patch
Type: text/x-diff
Size: 580 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090314/98ea1540/attachment.bin>