<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5"><br>
</div></div>Hrm, patch was empty in my mail client.<br>
<div class="im"></div></blockquote><div><br>I'll just inline it in the mail - it's a one liner:<br><br>Index: classmodel.cpp<br>===================================================================<br>--- classmodel.cpp    (revision 939163)<br>
+++ classmodel.cpp    (working copy)<br>@@ -397,7 +397,7 @@<br> <br>   for(uint a = 0; a < itemCount; ++a) {<br>     // Don't insert unknown or forward declarations into the class browser<br>-    if (items[a].kind == CodeModelItem::Unknown || items[a].kind == CodeModelItem::ForwardDeclaration)<br>
+    if ( (items[a].kind & CodeModelItem::Unknown) || (items[a].kind & CodeModelItem::ForwardDeclaration) )<br>       continue;<br><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>
> And with regards to what you're doing there, are you fixing the class<br>
> browser yourself? I don't want to do redundant work in that area.<br>
<br>
</div>I have made it a bit more reliable (updates properly), but haven't tested it<br>
very well.  A good project to help understand qt model/view would be to get<br>
the search line working.<br>
<div class="im"></div></blockquote><div><br>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.<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>
> I was thinking of doing a whole refactoring of the code there - one of 2<br>
> things (I must say first that these ideas came up before I've updated the<br>
> code to reflect your new changes so maybe you've done something in the<br>
> directions I list here):<br>
><br>
>  1. Drop the whole model / view architecture currently used there, our<br>
> "model" concept is actually the DUChains. Instead of doing another model<br>
> class which translates and caches many information from the DUChains to the<br>
> QT model design, I'll simply modify the "view" (The QTreeView in our case)<br>
> to fit our model existing model (the DUChains). So far, from what I've<br>
> seen, the model concept is deeply used within QT and changing the model<br>
> concept used there is abit askew.<br>
<br>
</div>The class model is a wrapper between duchain and qt's model/view architecture.<br>
The basic structure has to be duplicated due to multi-threading (model/view<br>
can't accept non-gui thread additions/removals, etc) and other considerations<br>
(this is why we need our own nodes).<br>
<div class="im"></div></blockquote><div><br>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.<br>
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.<br><br>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).<br>
<br></div><br></div><br></div>