This is a document to record the various design decisions.

+++StateEditor:
a state is defined as a complete assignment of values to variables (features).  
To this end we will force the user to assign the values by pre-assigning them.  The user may then update the values as they see fit.

It was decided that the States would be changed to being incomplete assignments.
The change was implemented by having a statically defined "any value" value that would be automatically 
assigned to all of the variables when they are added to the state.  the user may then change them to an actual value when they see fit.

+++Conditions:
at this point the conditions are going to be simple, only a value associated with a variable.  This will change with time.  
This program is designed to allow for that change easily.

I seem to have designed conditions incorrectly.  
I will need to work through this.
Presently there are numerous preConditions and Numerous post-conditions for a given Action.  This is wrong.  
There should be one pre and post condition which would then map down to the multiple mappings.

August 11th.
Did the refactoring.  Presently it is utilizing something akin to the Strategy Design pattern. 
That is, the StripsCondition is now a class that contains (most) all of the functions needed to interact with a Condition.
It is also abstract and thus must be extended

Proper usage is for future extension to extend the StripsCondition class and then modify a few lines of code in the 
rest of the applet that rely upon the class type.

+++Conversion:
The conversion system works by the user going into the "solve" tab and then pressing the buttons for the corresponding CSP applets.
The system will then convert the STRIPS problem to CSP and then launch the applet corresponding to the button.

+++Graphs and Data:
When first created there was a belief that the conversion would take place independent of the position of the nodes in the graph.  
In fact, it was believed the user would not be able to control the node placement.  This lead to a desire to break apart the 
core "data" in the strips problem from the visual elements tied to it in the graph.  This was, of course, the wrong thing to do.
The graph does almost entirely contain the problem, as a proper model in the MVC design pattern describes, it should be possible to
wrap them together in the future as simply the graph.  The only missing piece would  be the Start and Goal states which have 
no visual representation.

+++Problem Descriptions:
I'm deciding to put them in the graph to anticipate future roll-ups of the graph and problem.

+++Domain changes
When a variable domain is changed the main applet will receive a list of removed values.  Presently the applet then goes and quieries the 
conditions of the actions associated with each outgoing edge as to whether it should be removing them.  The condition then determines if the edge
should be.  Thus the decision about removing an edge is left to the condition rather than anything else. This will facilitate different 
types of conditions better.

+++Todo

Undo/Redos
Graphical bugs
	- zooming
	- Autoscaling
"In the detailed description of the generated CSP, you should say what version of the program produced it, 
the date, the source file (if known): i.e., enough to reproduce the example."
change names to not have > in them.  
- make a full coffee table delivery example  		done


