[Gzz-commits] gzz/doc/pegboard/vob_considerations--benja peg.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      02/12/06 14:54:19

Modified files:
        doc/pegboard/vob_considerations--benja: peg.rst 

Log message:
        Finish vob history; next is analysis

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/vob_considerations--benja/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/vob_considerations--benja/peg.rst
diff -u gzz/doc/pegboard/vob_considerations--benja/peg.rst:1.1 
gzz/doc/pegboard/vob_considerations--benja/peg.rst:1.2
--- gzz/doc/pegboard/vob_considerations--benja/peg.rst:1.1      Fri Dec  6 
14:07:40 2002
+++ gzz/doc/pegboard/vob_considerations--benja/peg.rst  Fri Dec  6 14:54:19 2002
@@ -4,8 +4,8 @@
 
 :Author:       Benja Fallenstein
 :Date:         2002-12-07
-:Revision:     $Revision: 1.1 $
-:Last-Modified:        $Date: 2002/12/06 19:07:40 $
+:Revision:     $Revision: 1.2 $
+:Last-Modified:        $Date: 2002/12/06 19:54:19 $
 :Type:         Architecture
 :Scope:                Major
 :Status:       Incomplete
@@ -84,4 +84,69 @@
 Second stage: Coordinate systems
 ================================
 
-In the second stage, invented by Tuomas in Spring 2002, 
\ No newline at end of file
+In the second stage, invented by Tuomas in Spring 2002, modified
+the system by introducing *coordinate systems*. A coordinate system
+is defined by a coordinate transformation (translation and scale
+or possibly a full affine transformation) relative to the canvas.
+It is coordinate systems that take identities (keys) in this system,
+not vobs. A vob is placed in one or more coordinate systems;
+cell vobs are placed in a single coordsys, connection vobs are
+placed between the two coordinate systems they connect.
+This system allowed the practical integration of connections
+into the vob system proper.
+
+In this system, vobs do not necessarily represent
+an object with an identity; those showing cells do, those
+showing connections don't (these vobs represent the relation
+between two different identities). Probably it can be said
+that some vobs in this pattern represent objects with
+identity; these vobs fill the corresponding coordsys with content
+(for example, the cell vobs fill the coordsys for that cell).
+Other vobs represent annotations to these objects; these do
+not fill a coordsys, but draw over or near to it
+(for example the connections, but possibly also a vob
+that shows a little icon right next to a cell to indicate
+something about the cell).
+
+It is still basically assumed in this system that there
+is a set of identities, and each coordsys represents one member
+of that set. In practice, however, even if most coordsys represent cells,
+it is common practice for some to hold other stuff (for example
+the name of the currently shown view etc.).
+
+
+Third stage: Hierarchical coordsys
+==================================
+
+The next step, getting us to the current vob system, was to
+introduce a *hierarchy* of coordinate systems. In this paradigm,
+the canvas is a coordinate system in itself, the *root coordinate system*.
+Other coordinate systems can be placed inside it, and yet other
+coordinate systems can be placed into *those* coordinate systems.
+
+This provides a way to finally break up the monolithic cell vobs,
+combining border, background, and cell content in a single vob.
+Since the cell content can be in a coordinate system
+inside the border's, it can be scrolled relatively to the border,
+showing a line cursor in the middle of the visible area.
+While hierarchical coordsys can also be used for
+showing a set of cells inside another cell, for example,
+this kind of assembling a bigger object from smaller parts
+was an important reason for moving to hierarchical coordsys
+in the first place.
+
+In this stage, we finally truly depart from the notion
+that there is a single set of identities and each coordsys
+represents one of them. At some levels in the hierarchy
+this is still true; a zzstructure view still places coordsys
+representing cells into the vob scene. But a coordsys for
+"the contents of a cell, scrolled to show the line cursor
+in the middle" works in a different way. We use role
+keys to represent this kind of thing.
+
+(Note: A coordsys c1 inside coordsys p1 is interpolated
+to c2 inside p2 if the keys of c1 and c2 are equal, and if
+p1 is interpolated to p2. This is somewhat similar
+to the vob paths from above.)
+
+