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
       applying "named" environments to arbitrary commands or debug sessions
       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 autoconf 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

