This is a list of features that could appear in future versions of this product. (Note: See the readme.txt for a list of known issues or defects) Work that we are planning or considering doing: 1. Eclipse Version - We will be moving up to later releases of Eclipse as they become stable. 2. Proper Handling of Setting Environment - In the current release, the support for setting\modifying environment variables is not complete. A proper mechanism of overriding system environment variables is needed. 3. PA Integration - We will be providing some level of integration with other plugins such as Performance Analysis. 4. Limited support for Mixed Language Projects - We need to look at the issues that arise from having Java, C/C++ and other languages in the same project. 5. Code Generation Tools/SmartGuides 6. Miner Development - We plan to create documentation and provide views that help users who wish to extend this product by writing their own miners. 7. Importing Parse Information From Other Projects - It would be nice if you could parse some code that is used a lot such as an include directory, and then import that parse information into one or more other projects. 8. Parser Features - Full C++ Support (partially tested) - Support for some or all of the GCC Language Extensions and\or support for non-ANSI C\C++ - Performance Improvements (there are *lots* of areas where performance can be improved) - Populate and make use of a database to store/retrieve parse information 9. Makefile.am Parser - to derive a view from it and user can actually easily navigate through the Makefile.am 10. Project Management using autovonf and automake - In the current release it has a limited ability for updating Makefile.am variables - meaning that a subset of these variables get updated Suggestions for work that you may consider interesting or worthwhile 1. Metrics - The DataStore is essentially just a tree of objects. This makes the job of writing tooling that consumes this information very straight-forward. A program metrics tool that calculates things like number of functions, complexity, or any other standard measurements would be a good way to familiarize yourself with writing Miners. 2. Class/Include Hierarchy Views - We are currently storing, in the DataStore, all the information required to create a Visual Graph of both the Class Hierarchy and Include File Hierarchy. We have not however, investigated what is required to implement a robust layout manager using the GEF (Graphical Editing Framework) in Eclipse 3. Refactoring - Another useful tool could be a C++ refactoring tool. Two notes of caution here: We have not tested any sort of round-tripping of the parse information (i.e. using the parse information to re-generate the code), so instead of trying to re-gen code, a better implementation would be just to use the information in the DataStore to find where objects are used and then handle the re-naming through some simple file operations. C++ symbol resolution in the parser does not conform 100% to the language definition for reasons of performance. Rather than producing a fully compliant parser, we prefer a solution that identifies potentially dangerous situations (e.g. some uses of templates) and doesn't proceed automatically in those cases. 4. Test Case Generator - Since we have parse information down to the statement\expression level, a tool can be written that automatically creates test cases that test each branch of a conditional statement for example Debugger issues: 1. Breakpoints - Set entry breakpoint - Set address breakpoint - Set watchpoint - Set dll/object load breakpoint - Add condition 2. Source - Disassembly view for files not in project - Mixed view 3. Monitor view - Disable monitor(even if disabled, it gets updated when tree is expanded) - Type information(creating type info degrades performance) - Change representation 4. Gdb console - update ui for any command executed 5. Exception Handling - Rerun Exception 6. Storage view - Removing