Version: 4 (svn 974261) (using KDE 4.2.3) Installed from: Ubuntu Packages [Current behaviour:] When I start KDevelop 4 (with no project open by default), an empty class browser is initially shown with one closed and empty top-level item "All Projects Classes". When I then open a project from the "Project >> Open Recent" menu, nothing happens in the class browser. (When I open the top-level item, it is still empty). When I then wait for some time, the projects classes appear as icon-less child-items of the top-level-item, with themselves no child items other than two empty folders for based/derived classes. When I however switch to the "Projects" panel, double click some .h file of the project containing a class definition (to open it in the editor), and then switch back to the class browser, all the project's classes and all their methods/properties are properly shown (including icons) right away. [Expected behaviour:] When starting KDevelop with no projects open and the class browser visible, it should be empty. When some project is then opened, it's source files should start being be scanned and the information properly added to the class browser immediately. If this takes time, some kind of non-intrusive animation should be shown inside the class browser's tree view to give visual feedback on the fact that new sources with potentially new class-info were added successfully, but have not yet finished being scanned. [Further suggestions:] 1) Remove the "All Projects Classes" top-level item. It merely increases the spacing to the left of all lower-level items, wasting precious horizontal space. If it is only meant to inform the user that all project's classes are shown here, a label above the tree view should replace it. If it is meant to in the future also show different collections of things than "All Projects Classes", it might be replaced by a combo-box or mutually-exclusive toggle-buttons or something similar above the tree view. 2) Please waste less horizontal space. In addition to the redundant top-level item, the spacings between the expanding icon (in my case a little triangle) and the actual item's icon is also really wide. Compare to the tree view in the "Projects" panel where the spacing is much more condensed compared to here, thus making it much more usable without having to make the panel so wide that it takes too much space from the actual editor. This is especially important since the class browser is a panel that you might want to keep open while actually coding.
Can you check under Settings->Configure KDevelop->Project wether "schedule all files for parsing" is activated? If that option is activated this works fine for me, classes are even populated during the parsing process. Also it would be better to have separate reports for each wish so we can properly track which things are implemented and which are not. So for the further suggestions please open individual reports.
SVN commit 974451 by zwabel: Reduce indentation in the class-view to the same level as in the project-view CCBUG: 194532 M +1 -0 classtree.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=974451
SVN commit 974455 by zwabel: Expand items on single-click on the name. With the lower indentation, the '+' is hard to hit. CCBUG: 194532 M +5 -0 classtree.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=974455
Thank you Andreas for pointing this out, with that option set it works for me also. Wouldn't it be a good idea to also tell the user about this in the class browser itself, rather than to wait for them to complain on the bugtracker (or elsewhere) like I did? For example, when applicable, a floating text could appear at the bottom of the treeview reading "n source/header files in currently opened projects not yet parsed. *Info...*", where "*Info...*" would be a link which, when clicked/hovered would show an interactive tooltip reading "Click here to *parse all now*. Also, you may *configure* Kdevelop to automatically parse all files when loading a project." (Where the links would, when clicked, bring about the expected action / take you to the relevant configuration page.) Also, for me it takes quite a few seconds until the entries start showing up in the class browser, so what do you think of my feedback animation idea mentioned in the original bug description? By the way, thanks to David for those two small but useful fixes.
(In reply to comment #4) > Wouldn't it be a good idea to also tell the user about this in the class > browser itself, rather than to wait for them to complain on the bugtracker (or > elsewhere) like I did? I don't think we need to do that, because that option needs to be on by default. Its just not that way yet because the parsing took quite a long time and used lots of memory in the not-so-distant past. In the next beta it'll probably activated by default. > Also, for me it takes quite a few seconds until the entries start showing up in > the class browser, so what do you think of my feedback animation idea mentioned > in the original bug description? We already have ideas about introducing feedback information in the toolview buttons as well as a better progress widget in the bottom right corner. (including bugreports for that even I think)