Feb 27, 2014 UPDATE:

As you may have noticed, this project is a bit chaotic and neglected at the
moment. Nevertheless, I still fully intend to complete it. More importantly,
I'd like to clean up the documentation and the project as a whole.

That being said, I'm a little busy finishing up college and working on another
project at the moment. And I'm sure work will keep me sufficiently busy once I
start as well. But if you would like me to priortize getting this project into
a better state, shoot me an email (matcatprg@yahoo.com) so I can do so.

Things I'd like to do right away:

. Cleaning up documentation. On the order of rewriting ALL of it from scratch,
using the old docs only for the information they contain.

This includes changing this README to be the sole user document, written in
something human readable (probably asciidoc) rather than straight up docbook
(live and learn.)

Would also create secondary documents INSTALL and TODO.

. Renaming the project.

I've had an idea for renaming the project for about 2 and a half years now. I
still like the name, so I probably will when I get the chance.



As for the code itself, I'd probably just want to refactor and clean up
functionality for the time being. Fix bugs and the like. Could add features
farther in the future when I have a better idea of what I'm doing.

As always, feedback is welcome.

Matthew Todd

--------------------


This file is a dump of random things I need to keep track of or might need
later.

For the documentation, please see manual.dbk, which is periodically built and
hosted here: http://matcatc.github.com/Test_Parser/

--------------------

This project started as an attempt to create some sort of visualizer for the
boost unittest framework. So instead of having some horrendous command line
output, a developer could have something a little easier on the eyes.

I'm trying to design it so that the program can work with any test framework.
One would just have to switch out for a different parser and runner. 

This is my first Python project (serious coding with an final application in mind.)
I'm using python 3.x.
The doxygen file is setup to use doxypy. See documentation.

Please give feedback. If you find something that bugs you enough to complain
about it, its important enough to send me an email. Same goes for positive
aspects as well. If I get no feedback, I have no clue how well this software
functions in the user's perspective.

Matthew A. Todd


----------------------------

Road Map:
	
It might be nice if the GUI could run arbitrary Python scripts. The idea being
that an user could run a script which compiles the test runner then calls run
on it. I'm assumming we're going to want to pass in something into it the
script call so that scripts will have a reference to some of the data. Possibly
the model (which would use Observer pattern to notify the display should the
script change the model's data somehow.) I guess a question is whether the
script would ever want to do something to the gui. I suppose its possible, so
we should allow for it, meaning we need to give a reference to the Gui as well.
If we have a containing class which contains all the particpating objects in
the running program, it would be a good option to pass in.


License:

This project is licensed under GNU GPL v.3. See COPYING for more info