X-Git-Url: http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=src%2Ffileio.cpp;fp=src%2Ffileio.cpp;h=4a1c25f1de1c47bffd33280697acb425789eafe7;hb=676007c81e292079daaa7188f4fbf2757ae77ef8;hp=fedddea4fea6729a917fe15510420aa829bef802;hpb=eb0057e8a8145032152e4c417fcd102ef5a21484;p=architektonas

diff --git a/src/fileio.cpp b/src/fileio.cpp
index fedddea..4a1c25f 100644
--- a/src/fileio.cpp
+++ b/src/fileio.cpp
@@ -24,6 +24,85 @@
 #include "dimension.h"
 #include "line.h"
 
+/*
+How to handle connected objects
+-------------------------------
+
+Every Object has a vector<Object *> which enumerates all Objects connected to
+the one we're looking at. So it looks like we'll have to take a two pass
+approach to loading and saving.
+
+Basically, in the saving case, first we write out all objects, keeping a
+pointer-to-index-number record. Second, we loop through all the objects we
+wrote out, writing connection lists. Format (indices are 1-based):
+
+CONNECTIONS
+1: 12 3
+3: 1
+12: 1
+ENDCONNECTIONS
+
+In the reading case, we do pretty much the same: we construct pointer-to-index-
+number list, then read the connection list. The PTIN connects the index to the
+Object pointers we've created. Then we simply call the Object's Connect()
+function to connect the objects.
+
+Small problem though: How does a Dimension know which points on a Line it's
+connected to? This approach tells the Dimension it's connected to the Line and
+the Line that it's connected to the Dimension, but not which points.
+
+How to handle them then? Do we list the point with the Object pointed at? A
+Line can contain an infinite number of points to connect with besides its
+endpoints.
+
+So with each connection Object in the vector, there would also have to be a
+corresponding point to go with it, that would be gotten from the other Object's
+Connect() function. Or, instead of a point, a parameter value?
+
+Doing that, with the Line and a parameter "t", if t == 0 we have endpoint 1.
+if t == 1, then we have endpoint 2. With a Circle, the parameter is a number
+between 0 and 1 (scaled to 0 to 2π). With an Arc, the parameter goes from 0 to
+1, 0 being enpoint 1 and 1 being endpoint 2.
+
+How does this work for moving objects that are connected? Again, with the Line
+and Dimension. The Line's connections looks like this:
+
+Object *: dim1, t = 0
+Object *: dim1, t = 1
+
+Dimension looks like this:
+
+Object *: line1, t = 0
+Object *: line1, t = 1
+
+For Dimensions, it can query the connected object (if any) using something like
+GetPointForParameter(). That way it can figure out where its endpoints are. If
+there is no connected point, then it uses its internal point.
+
+
+Dimensions are special cases of lines: They have exactly *two* points and none
+in between. Therefore, the Dimension object only needs to have two points. But
+those points can be connected to multiple objects. The can also be connected to
+no points/Objects too.
+
+How to describe them and their connections (or lack thereof)?
+
+Would have to be a 2nd pass, after all objects have been written out in order.
+Then you could do something like:
+
+DIMCONNECTIONS
+8 (the Dimension #): 1 (the Object # for point 1) 1 (the Object # for point 2)
+ENDDIMCONNECTIONS
+
+
+
+Connection attributes: E.g., between a Line a Circle, it can be tangent,
+perpendicular, or an arbitrary angle. How to encode that information? It's not
+intrinsic to either the Line or the Circle, but is a function of the
+relationship between them by virtue of their connection.
+
+*/
+
 enum ObjectType { OTContainer, OTContainerEnd, OTLine, OTCircle, OTArc, OTDimension,
 	OTPolygon, OTText, OTImage, OTBlock, OTEndOfFile };