-// connect(toolAction, SIGNAL(ObjectReady(Object *)), this,
-// SLOT(AddNewObjectToDocument(Object *)));
-//This works, now how to scroll it???
-// QPixmap pm(256, 256);
+
+/*
+Here we set the grid size in pixels--12 in this case. Initially, we have our
+zoom set to make this represent 12 inches at a zoom factor of 25%. (This is
+arbitrary.) So, to be able to decouple the grid size from the zoom, we need
+to be able to set the size of the background grid (which we do here at an
+arbitrary 12 pixels) to anything we want (within reason, of course :-).
+
+The drawing enforces the grid spacing through the drawing->gridSpacing variable.
+
+ drawing->gridSpacing = 12.0 / Painter::zoom;
+
+Painter::zoom is the zoom factor for the drawing, and all mouse clicks are
+translated to Cartesian coordinates through this. (Initially, Painter::zoom is
+set to 1.0. SCREEN_ZOOM is set to 1.0/4.0.)
+
+Really, the 100% zoom level can be set at *any* zoom level, it's more of a
+convenience function than any measure of absolutes. Doing things that way we
+could rid ourselves of the whole SCREEN_ZOOM parameter and all the attendant
+shittyness that comes with it.
+
+However, it seems that SCREEN_ZOOM is used to make text and arrow sizes show up
+a certain way, which means we should probably create something else in those
+objects to take its place--like some kind of scale factor. This would seem to
+imply that certain point sizes actually *do* tie things like fonts to absolute
+sizes on the screen, but not necessarily because you could have an inch scale
+with text that is quite small relative to other objects on the screen, which
+currently you have to zoom in to see (and which blows up the text). Point sizes
+in an application like this are a bit meaningless; even though an inch is an
+inch regardless of the zoom level a piece of text can be larger or smaller than
+this. Maybe this is the case for having a base unit and basing point sizes off
+of that.
+
+
+*/