Hello Everybody.
I assume that currently no urgent problems have to be discussed here so I hope I'm allowed to discuss an additional symbol-browser point. This discussion may result in a requirement but currently I don't know in which requirement.
As I wrote before I see a problem in the long lists you get in the symbol-browser. In a object orientated software-project it may be possible to use the language depending hierarchy definitions to move elements from the top-level to deeper levels like class inheritance or nested name-spaces.
But in more old fashioned software-projects with no object-hierarchies like in C and not Cpp this will not help. The user has to define the hierarchy some how else. My proposal is to give the user to define package-hierarchies inside the symbol-browser which represent a user-define tree whose nodes can be used to carry all symbols like the user wants.
- The user defines a package-structure that works like a folder-system and where a package may contain sub-packages and sub-sub-packages and sub-sub-sub... . This package-structure will be saved as independent xml-file or as part of the project-file. May be, it will good to have more than one independent package tree to represent different views.
- The activated package-structure will be displayed in the symbol-browser and can now be used to move symbols in. Once a symbol is moved in a package or its sub-package its id will be saved in the corresponding package xml-node. It may be possible to insert the symbol-id in more than one independent package-tree.
- The configuration of the symbol-browser allows the user to disable the display of moved symbols outside of their packages. Once the symbol-parser finds a changed symbol its id will be searched in the active package tree to prepare the display there and only there. Thus the user has to open the package to se the symbol and to reach its source but not shown symbols do not disturb the searching.
My idea is not to replace the current behaviour of the symbol-browser completely but to extend it. some more questions have to be discussed for example how to deal with change symbol-ids It may be useful to have a special tomb-package for symbols not found anymore or a delivery-package for new symbols. It may be good to add comment to every package and perhaps this may be used later to define a doxygen grouping definition. May be that this kind of browsing is to different compared with the currently used Symbol-browser what results in implementing a Package-browser parallel to the symbol-browser.
And may be you tell me that this already exists and I just was not able to activated it (Jens may remember the "disable the MouseSap-plugin" discussion we had in the last days, very embarrassing). So please help me to fill the vacuum between my ears.
Best Regards,
Eckard.