Classbrowser thoughts

Lior Mualem lior.m.kde at gmail.com
Thu Jun 25 12:53:48 UTC 2009


> Hi guys!
Hi, sorry for taking too long to respond, I've been a little busy.

> 
> I have some questions and ideas for the Classbrowser plugin:
> 
> 1) PHP has a strange bug where I'm not sure if it's my fault or if the 
> classbrowser is doing something wrong. To reproduce, install the PHP 
> plugin from playground and open any .php file and insert something like
> 
> 
> class foobar extends IteratorIterator {
> }
> 
> 
> What you will notice:
> 
> the Classbrowser won't update itself automatically, you have to close 
> "all projects classes" and open it again to see the new class (foobar)
> 
> Strange thing is that the classbrowser _does_ update itself when I add 
> members of methods to a Cpp class. But that does not work for PHP. Why?

I tried that in PHP and you're right but when I try to do the same in CPP project, it works just fine so it leads me to believe that it has something to do with PHP specifically.

I connect to the BranchModified signal of the DUChainObserver. Perhaps the PHP doesn't cause this signal to fire for some reason?
This is the function on the class browser that's suppose to monitor changes: DocumentClassesFolder::branchModified. 
it then adds the file to a list of updates files and when idle, it re-reads them from the DUChains.

> 
> 2) Now look at any class in the class browser which has a base class. 
> When you go to the base class and its derived classes you can see the 
> first class again:
> 
> foobar
>    -> Base classes
>      -> IteratorIterator
>        -> Derived Classes
>          foobar
>          -> start from top ;-)
> 
> I think it would be good to either not show foobar in the list of 
> derived classes in this case. Or alternativly just show the name but 
> don't let the user expand this item.

I want the user to know all of the derived classes so hiding it is out of the question. I agree that it opens the door for abuse but it causes no trouble. 
It shouldn't be too much of a hassle to pass along a "hint" to the derived classes folder about the class to hide but I personally think that it will limit this ability for no real good reason other than "aesthetics". I rather have ease of navigation.

> 
> 3) If you have some levels expanded in the browser and close one of the 
> parent items and reopen it, all children below will be closed. For 
> example open foobar and its Base classes. Then trigger "all projects 
> classes" and foobar and all its children will be closed. This is 
> unexpected behaviour and annoying.

I agree. The reason for that is because information is loaded on demand and unloaded when it's no longer needed (to conserve resources).
To implement that behavior, we'll need to maintain a list of expanded items unfortunately I'm a little bit short on time right now to do it.
But it'll be best if you could open a bug report for that so it wont be forgotten.

> 
> 4) "all project classes" implies to me that the class browser can filter 
> by project. But this does not seem to work for me. I only have the 
> top-level item "all project classes".

It's there to allow other type of "special" top level folder such as bookmarked classes (an idea) or search results.
It's possible to separate the classes to different project if memory serve me but is there a need to do such a thing? When I work with CPP, I usually want to see the classes in all of my open projects. Maybe the name could be changed to something like "All classes".

> 
> 5) It would be good if the class browser would filter by language (I'd 
> say at top-level, and below that by project). It doesn't make much sense 
> to have cpp and php classes in one tree to me.
> 
> Also you might want to make the top-item(s) always expaneded if there is 
> only one. I.e. for someone who only works on cpp he would not want to 
> close the cpp language tree in the browser. Same would possibly count if 
> there's only one project opened.
> 
Yes, that's a good idea also.

I've added these 2 idea to the wiki: http://www.kdevelop.org/mediawiki/index.php/Class_Browser_stuff

If anyone wants to implement some of the features and send in a patch, I'd be happy to assist and inspect the patch but unfortunately, at the moment it's hard for me to find the time to implement them.





More information about the KDevelop-devel mailing list