//These are \link Laxkit::SomeData::dump_out <tt>dump_out(FILE *,int indent)</tt>\endlink,
//\link Laxkit::SomeData::dump_in(FILE*,int,Attribute**)<tt>dump_in(FILE*,int,Attribute**)</tt>\endlink,
//and \link Laxkit::SomeData::dump_in_atts(Attribute *att)<tt>dump_in_atts(Attribute *att)</tt>\endlink

/*! \page Interfaces How to use the Interfaces

For complete interface class listings, see <a href="group__interfaces.html">here</a>.

\verbatim
***Insert Laxkit Interfaces tutorial here!!!
***WRITE THIS BETTER!!!!! please note that the below is quite out of date..
If you are reading this, tell the devs to update this right now!
\endverbatim

\section data A Word About Data

Most of the interfaces act on one kind of data. Usually, the data is defined in the same files
as the interface. All the data classes are derived from LaxFiles::DumpUtility, and thus have
easy file i/o with idented file data, a la LaxFiles::Attribute.

The dump_in() function by default just does a whole attribute dump in, and then calls
dump_in_atts(), so derived classes need only redefine the dump_in_atts() function. This is
usually fine, since the Attribute class is much easier to deal with then reading in straight
from the file.

\section refreshing Refreshing

An interface can either draw its own data, or it can be passed temporary data to draw
through DrawData(Displayer *, SomeData *, anOject *, anObject *). Each case calls the interface's 
Refresh() function, but the DrawData should replace all relevant state with what makes the temporary
data draw appropriately. If an interface defines the Context() method, then the ViewportWindow will
set the proper transform according to what Context() returns, so it need not be done in Refresh()
itself.

\todo At some point it might be prudent to separate rendering from the windowing. There would then
  be 3 components per interface: the object itself, the renderer, and the interface.





*/

