<div dir="ltr"><br><br><div class="gmail_quote">On Sat, Mar 14, 2009 at 12:29 AM, Hamish Rodda <span dir="ltr"><<a href="mailto:rodda@kde.org">rodda@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Saturday 14 March 2009 08:05:23 David Nolden wrote:<br>
> Am Freitag 13 März 2009 21:46:03 schrieb Lior Mualem:<br>
> > Hi,<br>
> > I'm trying to display a list of base classes within the class browser and<br>
> > I see that the base classes list is Cpp specific - in<br>
> > Cpp::ClassDeclaration thus it exists only within the KDevelop project and<br>
> > not under the kdevplatform project (which is where the class browser<br>
> > should be).<br>
><br>
> There is a slight duplication in this regard. You can also get to the base<br>
> classes through the context structure:<br>
> Declaration* declaration = Declaration of a class<br>
> foreach(DUContext::Import import, declaration->internalContext()-<br>
><br>
> >importedParentContext())<br>
><br>
>  if(import.context()->kind() == DUContext::Class)<br>
>       then import.context()->owner() is the declaration of a base-class of<br>
> declaration<br>
><br>
> Notice that you always have to do a null-pointer check, for all the<br>
> pointers treated in that code.<br>
><br>
> > Is there a reason why a list of base classes shouldn't reside within<br>
> > something that's defined in kdevplatform (atleast an interface class)?<br>
><br>
> I think we were thinking about moving Cpp::ClassDeclaration to<br>
> kdevplatform, but haven't come to it yet.<br>
<br>
</div>That would be good, i had to duplicate much of it for java.</blockquote><div><br>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).<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
<snip><br>
<div class="im"><br>
> > P.S: Is there developer documentation that explains the idea behind the<br>
> > different classes and their relations with regards to DUChains?<br>
><br>
> I think Hamish Rodda has written some documentation, I don't know where it<br>
> can be found though.<br>
<br>
</div><a href="http://api.kde.org/4.x-api/kdevplatform-%0Aapidocs/language/duchain/html/index.html" target="_blank">http://api.kde.org/4.x-api/kdevplatform-<br>
apidocs/language/duchain/html/index.html</a><br>
<div class="im"></div></blockquote><div><br>Thanks, I'll have a look at it later. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> So how far have you come with the class-browser? At some point I might peek<br>
> at what you've done. The most important thing is that it should be fast.<br>
> You should remember that whenever you call<br>
> KDevelop::IndexedDeclaration::declaration(), it may mean a complete file<br>
> has to be loaded from disk. For that reason, the actual duchain<br>
> declarations or contexts should only be used for displaying detailed<br>
> information that is actually visible on the screen. All other content of<br>
> the class-browser should use the simple representation from<br>
> KDevelop::CodeModel(It is maybe a bit too simple, but with some tricks, it<br>
> can be used to build a hierarchy)<br>
</div></blockquote><div><br>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).<br>
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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
</div>I fixed the code browser a few days ago, it works pretty well now except that<br>
for some reason the forward declarations are still displayed even though I've<br>
filtered out any CodeModel::ForwardDeclarations.<br>
</blockquote><div><br>On that note, I actually found this bug while playing with the existing code - under the function ClassModel::refreshNodes:<br>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. <br>
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)<br><br><br>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. <br>
<br>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):<br>
<br> 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.<br>
<br> 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).<br>
<br>I hope I got my ideas over, It's a little bit late here now ;)<br></div></div>Lior<br><br><br></div>