1.1 --- a/1__Development/0__Code_Dev/0__main_branch__netbeans_dev/src/EQNLangSrcHolder/EQNLangSrcVisualizer/EQNLangSrcVisualizer.java	Sun Jul 06 12:02:12 2014 -0700
     1.2 +++ b/1__Development/0__Code_Dev/0__main_branch__netbeans_dev/src/EQNLangSrcHolder/EQNLangSrcVisualizer/EQNLangSrcVisualizer.java	Wed Jul 23 18:51:15 2014 -0700
     1.3 @@ -122,7 +122,7 @@
     1.4         /*
     1.5          * Build a GraphicalElement for a line with the 
     1.6          * appropriate LineGraphicalElemParams. The line begins somewhere 
     1.7 -        * newar the center of the canvas and ends near its upper left corner
     1.8 +        * near the center of the canvas and ends near its upper left corner
     1.9          * (canvas origin).
    1.10          */
    1.11         child.nextElem = new DisplayElement();

     2.1 --- a/1__Development/0__Code_Dev/Javascript_approach/DESIGN_NOTES__14_Jn_22.txt	Sun Jul 06 12:02:12 2014 -0700
     2.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/DESIGN_NOTES__14_Jn_22.txt	Wed Jul 23 18:51:15 2014 -0700
     2.3 @@ -40,8 +40,9 @@
     2.4  
     2.5  -] Right, so one way to combine visualizers in a hierarchy, is for higher level visualizers to specify a lower-level one that is to fill in the internals of a given bounding box.  So the lower-level is sent the bounding box, and it generates a view hierarchy that fits inside of that.  Not sure whether the Display should be the one that sends the requests and integrates the various responses, or the Visualizer should send the requests and integrate the responses.
     2.6  
     2.7 +
     2.8  ==============================================
     2.9 -=
    2.10 +=         Display   Design  
    2.11  =
    2.12  ==============================================
    2.13  So, question..  what do display list elements look like?  Does visualizer produce the layout, for example, specify a bounding box and position for each element, including text, lines, etc?  Does it produce the bezier curves in SVG that connect syntax graph elements?
    2.14 @@ -72,12 +73,18 @@
    2.15  
    2.16  Now.  The question comes up..  what format?  Does the visualizer send out SVG?  Is that universal enough?  Will that cause problems with non-browser based approaches?  If not SVG, then what?  Will need to represent paths..  does visualizer calculate Bezier curves and send those?  Or does it just say "here are end points, connect these with a smooth path"?  Does the visualizer calculate how to route arcs within a graph around the other nodes in an optimal way?  If the user supplies helpers by moving things, does the Display remember that, or the Visualizer?  
    2.17  
    2.18 -Ahhhh..  okay..  if what the user to be able to affect the visual arrangement, then need to remember the gestures they give that are related to visual arrangement..  for example, they grab bezier control points and move them, in order to affect a curve, or add new points within a path in order to route it..  those things have to be remembered!  The Display has no place to store such things!!
    2.19 +Ahhhh..  okay..  if want the user to be able to affect the visual arrangement, then need to remember the gestures they give that are related to visual arrangement..  for example, they grab bezier control points and move them, in order to affect a curve, or add new points within a path in order to route it..  those things have to be remembered!  The Display has no place to store such things!!
    2.20  
    2.21  Right..  that means that the holder must store info related to viewing the holder contents!  sooooo..  the visualizer must be the thing that generates any details that a person may want to adjust.
    2.22  
    2.23  Right.  Any visual arrangement that a person might want to adjust must be stored inside the holder, and so the visualizer must be the thing that generates that level of detail.  Right.  Got it.
    2.24  
    2.25 +
    2.26 +
    2.27 +//========================  Visualizer Conclusions  ======================
    2.28 +//
    2.29 +//
    2.30 +//========================================================================
    2.31  So.  Yes.  That means that the visualizer must send out bounding boxes, translations, sizing, path points, control points, and so forth.  So.  Yes.  SVG is looking like a good way to go..  has to be something!  Can invent my own equivalent, which specifies paths, shapes, widths, and so forth..  but what is the gain?  The only potential is sending in binary, to save the overhead of SVG's text embodiment.  The savings worth the effort?  NO!
    2.32  
    2.33  Okay then.  SVG.  That is the visualizer's format for POP.  Or perhaps it just sends the values that go into the SVG?  The Display does the final conversion to text-based SVG format?  Hmmmm, what about custom syntax, which is SVG from the programmer?  Just send indication of SVG elements, together with the values?  Maybe enums for the SVG indicators, or something..
    2.34 @@ -88,7 +95,7 @@
    2.35  
    2.36  Heck, if send representation, then are already forcing SVG!  It doesn't constrain the Display if send the text form..  the display is just as free to convert the binary form to something else as it is to convert the text form to something else..  so if Display is not browser, and doesn't have SVG drawing primitives, it has to do the extra step of parsing SVG in order to extract the values from the text, and then generate whatever internal form it has, such as calculating paths or even pixels itself..  the extraction from text does not seem like a terribly large burden compared to the rest.
    2.37  
    2.38 -Buuuut..  don't really care!  Going to generate text form inside visualizer, because, why not?  Then the Display only translates displayList elements into its internal thing that paints.  In the case of browser, Display translates display list into famo.us elements, placing the SVG verbatim onto famous surfaces, and makes the SVG bounding box the same as the famous surface size.
    2.39 +Buuuut..  don't really care!  Going to generate text form inside visualizer, because, why not?  Then the Display only translates displayList elements into its internal thing that paints.  In the case of browser, Display translates display list into famo.us elements, placing the SVG verbatim onto famous surfaces, and makes the famous surface size the same as the SVG bounding box.
    2.40  
    2.41  In fact, display list is going to represent almost verbatim what a Famo.us render tree will look like!  It is a fairly universal declaration..  hierarchy of local visual contexts, with relationship among those contexts, including relative placement in 3D space and relative sizing from one to another.
    2.42  
    2.43 @@ -108,10 +115,65 @@
    2.44  
    2.45  Done.  Make it so.
    2.46  
    2.47 -BTW, thinking to introduce another component, which is a helper, that maybe takes some higher level view form and generates the view hierarchy from that..  this will ease the burden on developers who make custom syntax.. it will act as a library for them, essentially..  (and, of course, there will be a serializer that turns a view hierarchy into a stream of visual objects sent to the Display, which will reconstruct the view hierarchy then translate that into into elements that it paints.. for now, that serializer is just JSON!  It has provision to translate javascript objects into text form, and then on the other side parse that text form to reproduce the javascript objects.. might need extra logic in order to recreate the links among parents and children.. not sure whether JSON can go deep that way..).
    2.48 +BTW, thinking to introduce another component, which is a helper for developers making custom syntax, that maybe takes some higher level view form and generates the view hierarchy from that..  this will act as a library for them, essentially..  (and, of course, there will be a serializer that turns a view hierarchy into a stream of visual objects sent to the Display, which will reconstruct the view hierarchy then translate that into elements that it paints.. for now, that serializer is just JSON!  It has provision to translate javascript objects into text form, and then on the other side parse that text form to reproduce the javascript objects.. might need extra logic in order to recreate the links among parents and children.. not sure whether JSON can go deep that way..).
    2.49  
    2.50 +//======================================================
    2.51 +//					Code Reuse
    2.52 +//
    2.53 +//======================================================
    2.54  
    2.55 - 
    2.56 +Actually, there are multiple kinds of code re-use:
    2.57 +-] in-line code, where have something that assumes a context (such as variables in the scope), and grabs what matches within that context and inserts that into the respective places inside its body.  For example, a macro does this, so do in-line functions.
    2.58 +-] processors that are communicated with.  Many function calls are this -- other places in the code are other processors, that send parameters to the function, and receive back a return response.
    2.59 +-] inheritance, where have a namespace hierarchy that is searched.. the context can be assigned to a variable, then a function name can be looked up within it (assigning an object to a variable equals assigning a namespace to a variable).  If the function name isn't found in the immediate context, then the parent(s) of that context is(are) searched, until the name is found.  So, code is re-used by making it accessible from a parent name-space.
    2.60  
    2.61 +In POP, in-line code has four forms:
    2.62 +-] meta-agents inside the syntax-graph/MVDM-loop, which contain code that is used as part of generating code that is inserted into the syntax graph.  For example, active syntax generates code at the point that the user gives the gesture to add it to the syntax graph.
    2.63 +-] selecting a hierarchy unit to be deep-copied to the current hole in the syntax graph (the syntax-graph of the original is duplicated)
    2.64 +-] selecting a hierarchy unit to be reference-inserted into the hole (the syntax graph of the original is hooked to, not duplicated)
    2.65 +-] macros -- in POP these are both meta-agents and also deep copies.  The macro selects things from the code surrounding where it is placed, and sucks those inside itself, and puts in a copy thus modified, into the syntax graph.
    2.66  
    2.67 +In POP, processor-communicated-with code has at least two forms:
    2.68 +-] connecting the inputs and outputs of one code-processor to another (this can be implied, for example on a worksheet, or direct, using the MVDM loop while in System (OS) view)
    2.69 +-] when sending a context to a processor-box, it creates a new processor to handle the incoming context.  That is equivalent to copies of the code at runtime, talking to each other -- the creation as well as the contents is communication..  but it's not like other forms, where inputs are connected to outputs!
    2.70  
    2.71 +In POP, inheritance can be accomplished via the copy-by-reference mechanism, or via the send-a-namespace/context mechanism (simply insert the variable connected to the processor that you want to receive sent data.. same variable name in each context, connected to different processors == polymorphism..  and the parent context attached, that has functions attached to names in it == inheritance)
    2.72 +
    2.73 +In effect, POP has functional, object oriented, procedural, and declarative styles that can be done within it.  At least, the underlying mechanisms that set those things apart are all available within POP.
    2.74 +
    2.75 +==============================================================
    2.76 +==
    2.77 +==       Editor and Gesture and Commander and Modifier
    2.78 +==
    2.79 +==============================================================
    2.80 +
    2.81 +In famo.us, seeing putting up a rectangle that is placed in front of the others, and always in the plane of the camera, as the "menu"..
    2.82 +
    2.83 +always have a set of mappings to the keys -- these mappings are set by the commander inside the srcHolder -- they are specific to the kind of data being visualized.  In the case of code, for the moment, only visualizing the code in the form of a syntax graph (will do the custom syntax visualizer next -- it will have challenges don't want to get into just yet -- need a way to create syntax graphs and turn Gabe loose on search and match to patterns, so minimum path to that).
    2.84 +
    2.85 +So, seeing moving cursor around, and when hit a key, say the 'e' key, the port closest to the cursor will sprout an arrow that ends at the cursor..  the cursor is then moved to the target port and hitting e again locks onto there.. or perhaps just a left click, or perhaps space bar, etc..  choose in practice the one that feels most intuitive and convenient.
    2.86 +
    2.87 +When cursor is over empty background, hit a key, say the 'a' key, and that creates a new empty element box..  s creates a new empty properties box..  space bar brings up the menu that shows the key mappings.. or maybe ctl-space..
    2.88 +
    2.89 +another key zooms in on the elem or property box under the cursor
    2.90 +
    2.91 +inside the box, can hit a key to move cursor between fields -- at each field, can use space to pop up another menu and the un-pop it..  which has the starting sequences of the valid entries for the field (IE, a list of the elem types -- might itself be a hierarchical menu -- pick one of the keys or sequences from this menu, then that pops up another menu that has its own sequences or keys..  eventually a leaf is a value placed into that field) --  or the menu entry describes the format of what can be typed into the field (Ex, variable name format)
    2.92 +
    2.93 +===========
    2.94 +Soooo..  to make this work..
    2.95 +===========
    2.96 +
    2.97 +Each bounding box in famous has an event handler on it..  want the first enclosing bounding box to receive the event.  The bounding boxes must have parent links so that can navigate out to the boxes that enclose the target box.
    2.98 +
    2.99 +the event handler is fixed and generic to the Display..  however, the gestures understood are in an array that is given to the Display by the Commander.  When Display receives the "connect", it in turn sends a connect back to the Holder.  This asks for the Commander to be given to the Display.  It then tells the commander to give its gesture-handler pairs.
   2.100 +
   2.101 +In javascript, the "gesture-handler pairs" is an object that has a field for each gesture it understands, and the value of that field is the function that does the computation related to the gesture.  The function receives the event object, plus the smallest enclosing bounding box.
   2.102 +
   2.103 +The gesture-handler then turns the event plus bounding box into a command.  For example, if previously a gesture caused the start of the mode for typing text into a field -- say for entering the name of a variable -- then the gesture handler looks that up, within state enclosed with the gesture handler but shareable among different handlers.  The code then branches to where it extracts the key value from the event object.  It reuses a "key into field" command object, and packs it with data.  The data includes the model-object that is attached to the appropriate bounding box (the handler does the work of figuring out which bounding box corresponds to the syntax graph object that owns the field that is being typed into).  So, each bounding box has a back-link to the Model object that the shape inside the bounding box represents, where appropriate (IE, the bounding box for text has no back-link, but the bounding box for the element-box shape does have a back-link to the element object!)  Might make it just "useful info" -- for example, a text bounding box might include the name of the field of the object that the larger enclosing bounding box back-links to.  The gesture-handler will also extract any needed info from the event object, such as which key was pressed, and add that to the command-object.
   2.104 +
   2.105 +The command is then sent to the Modifier, which changes the back-linked-to syntax graph objects.  As part of that, it also modifies the visualized-sub-graph, and notifies the visualizer to update.
   2.106 +
   2.107 +
   2.108 +
   2.109 +
   2.110 +

     3.1 --- a/1__Development/0__Code_Dev/Javascript_approach/Display/app/GabePatternSrcHolder.js	Sun Jul 06 12:02:12 2014 -0700
     3.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/Display/app/GabePatternSrcHolder.js	Wed Jul 23 18:51:15 2014 -0700
     3.3 @@ -1,13 +1,17 @@
     3.4  
     3.5  
     3.6  //Make a SrcHolder object
     3.7 -define(function(require, exports, module) {
     3.8 +define( function( require, exports, module ) {
     3.9  
    3.10 -	var visualizer = require('./POPSyntaxGraphVisualizer');
    3.11 +	var visualizer  = require('./POPSyntaxGraphVisualizer');
    3.12 +	var commander   = require('./POPSyntaxGraphCommander');
    3.13 +	var modifier    = require('./POPSyntaxGraphModifier');	
    3.14  	var syntaxGraph = require('./buildGabePatternSyntaxGraph');
    3.15  
    3.16  	return{
    3.17 -		visualizer: visualizer,
    3.18 +		visualizer:  visualizer,
    3.19 +		commander:   commander,
    3.20 +		modifier:    modifier,
    3.21  		syntaxGraph: syntaxGraph
    3.22  	};
    3.23  });

     4.1 --- a/1__Development/0__Code_Dev/Javascript_approach/Display/app/POPApp.js	Sun Jul 06 12:02:12 2014 -0700
     4.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/Display/app/POPApp.js	Wed Jul 23 18:51:15 2014 -0700
     4.3 @@ -11,31 +11,33 @@
     4.4  	//get the Display object, which contains a function for passing a view
     4.5  	// hierarchy, which the Display then paints onto the screen
     4.6  	var POPDisplay = require('./POPDisplay');
     4.7 -	
     4.8 -	//test that have the require system working properly -- logs to console
     4.9 -	POPDisplay.acceptViewList("testing accept view list");
    4.10 -
    4.11 -	//invoke the module that paints a canned sub-piece of the gabe pattern
    4.12 -	// syntax graph.. just so have something to see!  (for now.. remove later)
    4.13 -	require('./renderPOPSyntaxGraph');
    4.14 -	
    4.15 +		
    4.16  	//cause the source holder object to be made, which will in turn
    4.17  	// cause a graph of syntax objects to be built inside of it
    4.18  	// and also cause a visualizer object to be built inside of it
    4.19  	var srcHolder = require('./GabePatternSrcHolder');
    4.20  	
    4.21 -	//connect the srcHolder to the Display
    4.22 +	//back-link the visualizer, commander, and modifier
    4.23 +	//Note: can have multiple triplets, one for each kind of visualization
    4.24 +	// for example, these are for seeing graph form.. later will add a triple
    4.25 +	// for seeing the custom syntax form
    4.26 +	srcHolder.visualizer.setSrcHolder( srcHolder );
    4.27 +	srcHolder.commander.setSrcHolder(  srcHolder );
    4.28 +	srcHolder.modifier.setSrcHolder(   srcHolder );
    4.29 +	
    4.30 +	//connect the pieces together
    4.31  	//Not sure yet what final form this will take..  for now..
    4.32  	srcHolder.visualizer.connectToDisplay( POPDisplay );
    4.33 +	POPDisplay.connectToCommander( srcHolder.commander );
    4.34 +	srcHolder.commander.connectToModifier( srcHolder.modifier );
    4.35 +	srcHolder.modifier.connectToSyntaxGraph( srcHolder.syntaxGraph );
    4.36 +	srcHolder.modifier.connectToVisualizer( srcHolder.visualizer );
    4.37  	
    4.38 -	//Trigger the visualizer to build a view hierarchy and pass that
    4.39 -	// to the Display object, which in turn triggers the Display to build
    4.40 -	// a famous render tree corresponding to the view hierarchy, which paints
    4.41 -	// the syntax graph representation into the browser
    4.42 -	//This isn't the correct final form of how the visualizer determines
    4.43 -	// the portions of the graph to generate a view hierarchy from, but
    4.44 -	// it works for now, while developing..
    4.45 -	srcHolder.visualizer.setViewSubGraph( srcHolder.visualizer.syntaxGraph );
    4.46 +	//run test on the modifier, which in turn sends a sub-graph to the
    4.47 +	// visualizer, which in turn sends the view hierarchy attached to the
    4.48 +	// graph to the Display, which converts the hierarchy into Famous
    4.49 +	// render tree, which causes it to paint.
    4.50 +	srcHolder.modifier.runTest( );	
    4.51  	
    4.52  	//Once the system is complete, the view will be initialized to whatever
    4.53  	// the last view was before suspend.  When first built, the srcHolder

     5.1 --- a/1__Development/0__Code_Dev/Javascript_approach/Display/app/POPDisplay.js	Sun Jul 06 12:02:12 2014 -0700
     5.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/Display/app/POPDisplay.js	Wed Jul 23 18:51:15 2014 -0700
     5.3 @@ -12,62 +12,157 @@
     5.4  // what can be accessed by external functions that load this module, via
     5.5  // themselves using the require("POPDisplay") call
     5.6  define(function(require, exports, module) {
     5.7 -    //Create the famous infrastructure, which is used for rendering on screen
     5.8 -    var Engine           = require("famous/core/Engine");
     5.9 -    var Surface          = require("famous/core/Surface");
    5.10 -    var Modifier         = require("famous/core/Modifier");
    5.11 -    var Transform        = require('famous/core/Transform');
    5.12 -    var StateModifier    = require('famous/modifiers/StateModifier');
    5.13 -    var ContainerSurface = require("famous/surfaces/ContainerSurface");
    5.14 +//Create the famous infrastructure, which is used for rendering on screen
    5.15 +var Engine           = require("famous/core/Engine");
    5.16 +var Surface          = require("famous/core/Surface");
    5.17 +var Modifier         = require("famous/core/Modifier");
    5.18 +var Transform 		 = require('famous/core/Transform');
    5.19 +var StateModifier 	 = require('famous/modifiers/StateModifier');
    5.20 +var ContainerSurface = require("famous/surfaces/ContainerSurface");
    5.21 +var EventHandler     = require('famous/core/EventHandler');
    5.22  
    5.23 -	//make the context, which controls rendering to the screen
    5.24 -	// once add something to this context, that add makes the thing visibly
    5.25 -	// have effect.
    5.26 -	//Note, these are available to the render function via the closure
    5.27 -	// mechanism
    5.28 -    var mainContext = Engine.createContext();
    5.29 +var commander = {}; //set by POPApp via a function (defined below) 
    5.30  
    5.31 -	var handleGesture = function( event ) {
    5.32 -			//not sure this is the right form, but provide a handler for
    5.33 -			// gestures made by the programmer/user
    5.34 -			//This will make an object that pairs the gesture to the view
    5.35 -			// element that is represented by the surface(s) involved in
    5.36 -			// the gesture.
    5.37 -			//It will then send the object to the command generator, which 
    5.38 -			// is part of the source holder
    5.39 -		console.log("handleGesture");
    5.40 +//make the context, which controls rendering to the screen
    5.41 +// once add something to this context, that add makes the thing visibly
    5.42 +// have effect.
    5.43 +//Note, these are available to the render function via the closure
    5.44 +// mechanism
    5.45 +var mainContext = Engine.createContext();
    5.46 +
    5.47 +var handleGesture = function( event ) {
    5.48 +		//not sure this is the right form, but provide a handler for
    5.49 +		// gestures made by the programmer/user
    5.50 +		//This will make an object that pairs the gesture to the view
    5.51 +		// element that is represented by the surface(s) involved in
    5.52 +		// the gesture.
    5.53 +		//It will then send the object to the command generator, which 
    5.54 +		// is part of the source holder
    5.55 +	console.log("handleGesture");
    5.56 +}
    5.57 +
    5.58 +function acceptViewList (viewHierarchy) {
    5.59 +	//Here, convert each view hierarchy element into an equivalent
    5.60 +	// famous render tree node
    5.61 +	
    5.62 +	//during testing, log some known positions within the hierarchy
    5.63 +	console.log("POPDisplay: " + viewHierarchy.rootBox.subBoxes[1].subBoxes[2].shape + " y: " + viewHierarchy.rootBox.subBoxes[1].subBoxes[2].yOffset);
    5.64 +
    5.65 +	//the root node is always a container, no matter what, and it always
    5.66 +	// is placed at the user-view origin, no matter what
    5.67 +	var rootContainer = new ContainerSurface({
    5.68 +		size: [viewHierarchy.rootBox.width, viewHierarchy.rootBox.height], 
    5.69 +		properties: {
    5.70 +			overflow: 'hidden'
    5.71 +		}
    5.72 +	});
    5.73 +	mainContext.add(rootContainer);
    5.74 +
    5.75 +	//If a node in the hierarchy has children, then it will have a famous
    5.76 +	// container that corresponds to itself.
    5.77 +	//The children will be offset relative to
    5.78 +	// the container's origin, and all will be transformed as a unit.
    5.79 +	// the node may also have a shape, in which case a surface with no
    5.80 +	// transform is added to the container.
    5.81 +	//While traversing the hierarchy, keep two queues of upcoming "parents"
    5.82 +	// one for parent containers, the other for the nodes that correspond
    5.83 +	// to those containers.  The container queue controls the loop "end"
    5.84 +	// condition..
    5.85 +	//Each time find a node that has children, push that node into a queue
    5.86 +	// and push the node's newly made container into a queue
    5.87 +	//When done with all current children, grab the oldest parent from the
    5.88 +	// queues.
    5.89 +	//
    5.90 +	//So, set up for these loops..
    5.91 +	var node = {}; var newSurface; var newSurfMod = {}; 
    5.92 +	var newContainer = {}; var newContMod = {}; 
    5.93 +	var i = 0; var numChildren = 0; 
    5.94 +
    5.95 +	var nextGenParentContainers = []; var nextGenParentNodes = [];
    5.96 +	var parent = rootContainer; 
    5.97 +	nextGenParentNodes.push( viewHierarchy.rootBox);
    5.98 +	while( parent != undefined ) {
    5.99 +		children = nextGenParentNodes.shift().subBoxes;
   5.100 +		numChildren = children.length; 
   5.101 +		console.log("numChildren: "+numChildren);
   5.102 +		for( i=0; i < numChildren; i++) {
   5.103 +			node = children[i];
   5.104 +			console.log("nodeID: " + node.ID);
   5.105 +			//check whether node has children -- if so, create a container so
   5.106 +			// that all children transform together, and have same origin
   5.107 +			if(node.subBoxes != null) {
   5.108 +				newContainer = new ContainerSurface({
   5.109 +					size: [node.width, node.height], 
   5.110 +					properties: {
   5.111 +						overflow: 'hidden'
   5.112 +					}
   5.113 +				});
   5.114 +				newContMod = new StateModifier({
   5.115 +					transform: Transform.translate(node.xOffset, node.yOffset, 0)
   5.116 +				});
   5.117 +				parent.add( newContMod ).add( newContainer );
   5.118 +				//now check whether the node has a shape to render
   5.119 +				if(node.shape != null) {
   5.120 +					newSurface = new Surface({
   5.121 +					  size: [node.width, node.height],
   5.122 +					  content: node.shape
   5.123 +					});
   5.124 +					//no transform.. using transform applied to container
   5.125 +					newContainer.add( newSurface );
   5.126 +				}
   5.127 +				//now add to list of parents in next outer-loop
   5.128 +				nextGenParentContainers.push( newContainer );
   5.129 +				nextGenParentNodes.push( node );
   5.130 +			}
   5.131 +			//Does node have a shape to render?
   5.132 +			if(node.shape != null) {
   5.133 +				newSurface = new Surface({
   5.134 +				  size: [node.width, node.height],
   5.135 +				  content: node.shape
   5.136 +				});
   5.137 +				//for this case, need a transform for the x and y offsets
   5.138 +				newSurfMod = new StateModifier({
   5.139 +					transform: Transform.translate(node.xOffset, node.yOffset, 0)
   5.140 +				});
   5.141 +				parent.add( newSurfMod ).add( newSurface );
   5.142 +			}
   5.143 +		}
   5.144 +		//finished all children of this node.. get new parent
   5.145 +		parent = nextGenParentContainers.shift();
   5.146  	}
   5.147 -	function acceptViewList (viewList) {
   5.148 -		//access Display object and its values here, as a closure
   5.149 -		console.log("acceptViewList");
   5.150 -	}
   5.151 -	
   5.152 -	function init() {
   5.153 -		console.log("init");
   5.154 -		//	var POPStuffToDraw = 
   5.155 -		var mySurface = new Surface({
   5.156 -		  size: [100, 100],
   5.157 -		  content: '<svg width="100" height="80"><rect x="30" y="10" rx="20" ry="20" width="50" height="50" style="fill:red;stroke:black;stroke-width:3;opacity:0.5">',
   5.158 -		  properties: {
   5.159 -			color: 'white',
   5.160 -			lineHeight: '200%',
   5.161 -			textAlign: 'center',
   5.162 -			fontSize: '36px',
   5.163 -			cursor: 'pointer'
   5.164 -		  }
   5.165 -		});
   5.166 -		var stateModifier = new StateModifier({
   5.167 -			transform: Transform.translate(250, 100, 0)
   5.168 -		});
   5.169 -		mainContext.add(stateModifier).add(mySurface);
   5.170 -	}
   5.171 +}
   5.172  
   5.173 +function init() {
   5.174 +	console.log("init");
   5.175 +	//	var POPStuffToDraw = 
   5.176 +	var mySurface = new Surface({
   5.177 +	  size: [100, 100],
   5.178 +	  content: '<svg width="100" height="80"><rect x="30" y="10" rx="20" ry="20" width="50" height="50" style="fill:red;stroke:black;stroke-width:3;opacity:0.5">',
   5.179 +	  properties: {
   5.180 +		color: 'white',
   5.181 +		lineHeight: '200%',
   5.182 +		textAlign: 'center',
   5.183 +		fontSize: '36px',
   5.184 +		cursor: 'pointer'
   5.185 +	  }
   5.186 +	});
   5.187 +	var stateModifier = new StateModifier({
   5.188 +		transform: Transform.translate(250, 100, 0)
   5.189 +	});
   5.190 +	mainContext.add(stateModifier).add(mySurface);
   5.191 +}
   5.192  
   5.193 -	return{
   5.194 -		init: init,
   5.195 -		handleGesture: handleGesture,
   5.196 -		acceptViewList: acceptViewList
   5.197 -	};
   5.198 +function connectToCommander( commanderIn ) {
   5.199 +	commander = commanderIn;
   5.200 +	console.log("display connect to commander");
   5.201 +}
   5.202 +
   5.203 +return{
   5.204 +	init:               init,
   5.205 +	connectToCommander: connectToCommander,
   5.206 +	handleGesture:      handleGesture,
   5.207 +	acceptViewList:     acceptViewList
   5.208 +};
   5.209  });
   5.210  
   5.211  

     6.1 --- a/1__Development/0__Code_Dev/Javascript_approach/Display/app/POPSyntaxGraphVisualizer.js	Sun Jul 06 12:02:12 2014 -0700
     6.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/Display/app/POPSyntaxGraphVisualizer.js	Wed Jul 23 18:51:15 2014 -0700
     6.3 @@ -3,144 +3,209 @@
     6.4  //Make a Visualizer object, and a number of functions that operate on it.
     6.5  // One of the functions accepts 
     6.6  define(function(require, exports, module) {
     6.7 -    //Create the famous infrastructure, which is used for rendering on screen
     6.8 +//Create the famous infrastructure, which is used for rendering on screen
     6.9 +
    6.10 +var srcHolder = {};
    6.11 +var DisplayToSendTo = {};
    6.12 +
    6.13 +var viewHierarchy = {};
    6.14 +
    6.15 +var renderer = require('./renderPOPSyntaxGraph');	
    6.16 +
    6.17 +
    6.18 +function init() {
    6.19 +	//access Visualizer values here, as a closure
    6.20 +	console.log("init visualizer");
    6.21 +}
    6.22 +
    6.23 +function setSrcHolder( srcHolderIn ) {
    6.24 +	srcHolder = srcHolderIn;
    6.25 +}
    6.26 +
    6.27 +function connectToDisplay( POPDisplay ) {
    6.28 +	//access Visualizer values here, as a closure
    6.29 +	DisplayToSendTo = POPDisplay;
    6.30 +	console.log("connectToDisplay");
    6.31 +}
    6.32 +
    6.33 +
    6.34 +//Calling this function triggers a series of events:
    6.35 +//1) it generates a view hierarchy that represents the syntax graph
    6.36 +//2) it sends that view hierarchy to the Display
    6.37 +//3) the Display creates an internal representation of the hierarchy
    6.38 +//4) the Display paints that internal representation to some device
    6.39 +function setViewSubGraph( syntaxSubGraph ) {
    6.40 +	//access Visualizer values here, as a closure
    6.41 +	console.log("setViewSubGraph");
    6.42 +	//for first pass, just build the view hierarchy by hand
    6.43  	
    6.44 -	var viewHierarchy = {};
    6.45 -	
    6.46 -	var renderer = require('./renderPOPSyntaxGraph');	
    6.47 -	
    6.48 -	function init() {
    6.49 -		//access Visualizer values here, as a closure
    6.50 -		console.log("init visualizer");
    6.51 +	//A view hierarchy consists of bounding boxes arranged in a
    6.52 +	// a hierarchy.  Inside each bounding box is either more bounding
    6.53 +	// boxes or a paintable thing, or both.
    6.54 +	//For now, paintable things are all SVG, even text is SVG text
    6.55 +
    6.56 +	//In this test, just construct the hierarchy for the two boxes
    6.57 +	// that already did the by-hand SVG for, with the bezier connecting
    6.58 +	// them..  for now, just make the data structs and populate with
    6.59 +	// info gotten from the by-hand rendering
    6.60 +	//Later, will calculate all the box sizes and positions relative to
    6.61 +	// parents, starting from the syntax graph
    6.62 +	var gottenElem = renderer.getRootBox;
    6.63 +	viewHierarchy.rootBox = {
    6.64 +		ID: gottenElem.ID,
    6.65 +		type:	'container',
    6.66 +		width: gottenElem.width,
    6.67 +		height: gottenElem.height,
    6.68 +		parent: null,
    6.69 +		subBoxes: []
    6.70 +	} //note, left out parent-relative position and shape!
    6.71 +	var currParent = viewHierarchy.rootBox;
    6.72 +	var children = currParent.subBoxes;
    6.73 +	//first child is the syntactic element box
    6.74 +	var gottenElem = renderer.getElemBox;
    6.75 +	children[0] = {
    6.76 +		ID: gottenElem.ID,
    6.77 +		type:	'shape',
    6.78 +		width: gottenElem.width, //match the SVG shapes inside
    6.79 +		height: gottenElem.height,
    6.80 +		xOffset: gottenElem.x,
    6.81 +		yOffset: gottenElem.y,
    6.82 +		shape: gottenElem.shape,
    6.83 +		parent: currParent,
    6.84 +		subBoxes: []
    6.85 +	}
    6.86 +	//second child is the properties box attached to the first box
    6.87 +	gottenElem = renderer.getPropertiesBox;
    6.88 +	children[1] = {
    6.89 +		ID: gottenElem.ID,
    6.90 +		type:	'shape',
    6.91 +		width: gottenElem.width, //match the SVG shapes inside
    6.92 +		height: gottenElem.height,
    6.93 +		xOffset: gottenElem.x,
    6.94 +		yOffset: gottenElem.y,
    6.95 +		shape: gottenElem.shape,
    6.96 +		parent: currParent,
    6.97 +		subBoxes: []
    6.98 +	}
    6.99 +	console.log("box2: " + children[1].shape);
   6.100 +	//third child is the bezier curve connecting the boxes
   6.101 +	gottenElem = renderer.getBezier;
   6.102 +	children[2] = {
   6.103 +		ID: gottenElem.ID,
   6.104 +		type:	'shape',
   6.105 +		width: gottenElem.width,
   6.106 +		height: gottenElem.height,
   6.107 +		xOffset: gottenElem.x,
   6.108 +		yOffset: gottenElem.y,
   6.109 +		shape: gottenElem.shape,
   6.110 +		parent: currParent,
   6.111 +		subBoxes: null
   6.112  	}
   6.113  	
   6.114 -	function connectToDisplay( POPDisplay ) {
   6.115 -		//access Visualizer values here, as a closure
   6.116 -		console.log("connectToDisplay");
   6.117 +	//now add the text to the elem box
   6.118 +	currParent = children[0];
   6.119 +	children = currParent.subBoxes; //set to subBoxes of elem box
   6.120 +	gottenElem = renderer.getText1_1_1;
   6.121 +	children[0] = {
   6.122 +		ID: gottenElem.ID,
   6.123 +		type:	'shape',
   6.124 +		width: gottenElem.width,
   6.125 +		height: gottenElem.height,
   6.126 +		xOffset: gottenElem.x,
   6.127 +		yOffset: gottenElem.y,
   6.128 +		shape: gottenElem.shape,
   6.129 +		parent: currParent,
   6.130 +		subBoxes: null
   6.131 +	}
   6.132 +	gottenElem = renderer.getText1_1_2;
   6.133 +	children[1] = {
   6.134 +		ID: gottenElem.ID,
   6.135 +		type:	'shape',
   6.136 +		width: gottenElem.width,
   6.137 +		height: gottenElem.height,
   6.138 +		xOffset: gottenElem.x,
   6.139 +		yOffset: gottenElem.y,
   6.140 +		shape: gottenElem.shape,
   6.141 +		parent: currParent,
   6.142 +		subBoxes: null
   6.143 +	}
   6.144 +	gottenElem = renderer.getText1_1_3;
   6.145 +	children[2] = {
   6.146 +		ID: gottenElem.ID,
   6.147 +		type:	'shape',
   6.148 +		width: gottenElem.width,
   6.149 +		height: gottenElem.height,
   6.150 +		xOffset: gottenElem.x,
   6.151 +		yOffset: gottenElem.y,
   6.152 +		shape: gottenElem.shape,
   6.153 +		parent: currParent,
   6.154 +		subBoxes: null
   6.155 +	}
   6.156 +	gottenElem = renderer.getText1_1_4;
   6.157 +	children[3] = {
   6.158 +		ID: gottenElem.ID,
   6.159 +		type:	'shape',
   6.160 +		width: gottenElem.width,
   6.161 +		height: gottenElem.height,
   6.162 +		xOffset: gottenElem.x,
   6.163 +		yOffset: gottenElem.y,
   6.164 +		shape: gottenElem.shape,
   6.165 +		parent: currParent,
   6.166 +		subBoxes: null
   6.167  	}
   6.168  	
   6.169 -	//Calling this function triggers a series of events:
   6.170 -	//1) it generates a view hierarchy that represents the syntax graph
   6.171 -	//2) it sends that view hierarchy to the Display
   6.172 -	//3) the Display creates an internal representation of the hierarchy
   6.173 -	//4) the Display paints that internal representation to some device
   6.174 -	function setViewSubGraph( syntaxSubGraph ) {
   6.175 -		//access Visualizer values here, as a closure
   6.176 -		console.log("setViewSubGraph");
   6.177 -		//for first pass, just build the view hierarchy by hand
   6.178 -		
   6.179 -		//A view hierarchy consists of a bounding boxes arranged in a
   6.180 -		// a hierarchy.  Inside each bounding box is either more bounding
   6.181 -		// boxes or a paintable thing.
   6.182 -		//For now, paintable things are either SVG or text
   6.183 -		//Text includes styles such as font, italics, size
   6.184 +	//now add the text to the properties box
   6.185 +	currParent = viewHierarchy.rootBox.subBoxes[1];
   6.186 +	children = currParent.subBoxes;
   6.187 +	gottenElem = renderer.getText1_2_1;
   6.188 +	children[0] = {
   6.189 +		ID: gottenElem.ID,
   6.190 +		type:	'shape',
   6.191 +		width: gottenElem.width,
   6.192 +		height: gottenElem.height,
   6.193 +		xOffset: gottenElem.x,
   6.194 +		yOffset: gottenElem.y,
   6.195 +		shape: gottenElem.shape,
   6.196 +		parent: currParent,
   6.197 +		subBoxes: null
   6.198 +	}
   6.199 +	gottenElem = renderer.getText1_2_2;
   6.200 +	children[1] = {
   6.201 +		ID: gottenElem.ID,
   6.202 +		type:	'shape',
   6.203 +		width: gottenElem.width,
   6.204 +		height: gottenElem.height,
   6.205 +		xOffset: gottenElem.x,
   6.206 +		yOffset: gottenElem.y,
   6.207 +		shape: gottenElem.shape,
   6.208 +		parent: currParent,
   6.209 +		subBoxes: null
   6.210 +	}
   6.211 +	gottenElem = renderer.getText1_2_3;
   6.212 +	children[2] = {
   6.213 +		ID: gottenElem.ID,
   6.214 +		type:	'shape',
   6.215 +		width: gottenElem.width,
   6.216 +		height: gottenElem.height,
   6.217 +		xOffset: gottenElem.x,
   6.218 +		yOffset: gottenElem.y,
   6.219 +		shape: gottenElem.shape,
   6.220 +		parent: currParent,
   6.221 +		subBoxes: null
   6.222 +	}
   6.223 +	console.log("visual elem: " + viewHierarchy.rootBox.subBoxes[1].subBoxes[2].shape + " y: " + viewHierarchy.rootBox.subBoxes[1].subBoxes[2].yOffset);
   6.224 +	//for now, just send reference to the viewHierarchy -- make this 
   6.225 +	// sane later (not sure whether will do a "class" and create 
   6.226 +	// instance via new operator, or what..
   6.227 +	DisplayToSendTo.acceptViewList( viewHierarchy );
   6.228 +}
   6.229  
   6.230 -		//In this test, just construct the hierarchy for the two boxes
   6.231 -		// that already did the by-hand SVG for, with the bezier connecting
   6.232 -		// them..  for now, just make the data structs and populate with
   6.233 -		// info gotten from the by-hand rendering
   6.234 -		//Later, will calculate all the box sizes and positions relative to
   6.235 -		// parents
   6.236 -		viewHierarchy.rootBox = {
   6.237 -			width: 500,
   6.238 -			height: 500,
   6.239 -			subBoxes: []
   6.240 -		} //note, left out parent-relative position and shape!
   6.241 -		
   6.242 -		var children = viewHierarchy.rootBox.subBoxes;
   6.243 -		//first child is the syntactic element box
   6.244 -		svgBox = renderer.getElemBox();
   6.245 -		children[0] = {
   6.246 -			width: 68, //match width and height of the SVG shapes inside
   6.247 -			height: 88,
   6.248 -			xOffset: 0,
   6.249 -			yOffset: 2,
   6.250 -			shape: svgBox,
   6.251 -			subBoxes: []
   6.252 -		}
   6.253 -		//second child is the properties box attached to the first box
   6.254 -		svgBox = renderer.getPropertiesBox();
   6.255 -		children[1] = {
   6.256 -			width: 185, //match width and height of the SVG shapes inside
   6.257 -			height: 71,
   6.258 -			xOffset: 100,
   6.259 -			yOffset: 2,
   6.260 -			shape: svgBox,
   6.261 -			subBoxes: []
   6.262 -		}
   6.263 -		console.log("box2: " + children[1].shape);
   6.264 -		
   6.265 -		//now add the text to the elem box
   6.266 -		children = children[0].subBoxes; //set to subBoxes of elem box
   6.267 -		var text1_1_1 = renderer.getText1_1_1;
   6.268 -		children[0] = {
   6.269 -			width: text1_1_1.width,
   6.270 -			height: text1_1_1.height,
   6.271 -			xOffset: text1_1_1.x,
   6.272 -			yOffset: text1_1_1.y,
   6.273 -			shape: text1_1_1.svg
   6.274 -		}
   6.275 -		var text1_1_2 = renderer.getText1_1_2;
   6.276 -		children[1] = {
   6.277 -			width: text1_1_2.width,
   6.278 -			height: text1_1_2.height,
   6.279 -			xOffset: text1_1_2.x,
   6.280 -			yOffset: text1_1_2.y,
   6.281 -			shape: text1_1_2.svg
   6.282 -		}
   6.283 -		var text1_1_3 = renderer.getText1_1_3;
   6.284 -		children[2] = {
   6.285 -			width: text1_1_3.width,
   6.286 -			height: text1_1_3.height,
   6.287 -			xOffset: text1_1_3.x,
   6.288 -			yOffset: text1_1_3.y,
   6.289 -			shape: text1_1_3.svg
   6.290 -		}
   6.291 -		var text1_1_4 = renderer.getText1_1_4;
   6.292 -		children[3] = {
   6.293 -			width: text1_1_4.width,
   6.294 -			height: text1_1_4.height,
   6.295 -			xOffset: text1_1_4.x,
   6.296 -			yOffset: text1_1_4.y,
   6.297 -			shape: text1_1_4.svg
   6.298 -		}
   6.299 -		
   6.300 -		//now add the text to the properties box
   6.301 -		children = viewHierarchy.rootBox.subBoxes[1].subBoxes;
   6.302 -		var text1_2_1 = renderer.getText1_2_1;
   6.303 -		children[0] = {
   6.304 -			width: text1_2_1.width,
   6.305 -			height: text1_2_1.height,
   6.306 -			xOffset: text1_2_1.x,
   6.307 -			yOffset: text1_2_1.y,
   6.308 -			shape: text1_2_1.svg
   6.309 -		}
   6.310 -		var text1_2_2 = renderer.getText1_2_2;
   6.311 -		children[1] = {
   6.312 -			width: text1_2_2.width,
   6.313 -			height: text1_2_2.height,
   6.314 -			xOffset: text1_2_2.x,
   6.315 -			yOffset: text1_2_2.y,
   6.316 -			shape: text1_2_2.svg
   6.317 -		}
   6.318 -		var text1_2_3 = renderer.getText1_2_3;
   6.319 -		children[2] = {
   6.320 -			width: text1_2_3.width,
   6.321 -			height: text1_2_3.height,
   6.322 -			xOffset: text1_2_3.x,
   6.323 -			yOffset: text1_2_3.y,
   6.324 -			shape: text1_2_3.svg
   6.325 -		}
   6.326 -		
   6.327 -		//now add the bezier curve
   6.328 -		
   6.329 -	}
   6.330 -
   6.331 -	return{
   6.332 -		init: init,
   6.333 -		connectToDisplay: connectToDisplay,
   6.334 -		setViewSubGraph: setViewSubGraph
   6.335 -	};
   6.336 +return{
   6.337 +	init: init,
   6.338 +	setSrcHolder: setSrcHolder,
   6.339 +	connectToDisplay: connectToDisplay,
   6.340 +	setViewSubGraph: setViewSubGraph
   6.341 +};
   6.342  });
   6.343  
   6.344  

     7.1 --- a/1__Development/0__Code_Dev/Javascript_approach/Display/app/buildGabePatternSyntaxGraph.js	Sun Jul 06 12:02:12 2014 -0700
     7.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/Display/app/buildGabePatternSyntaxGraph.js	Wed Jul 23 18:51:15 2014 -0700
     7.3 @@ -3,24 +3,49 @@
     7.4  // sub-properties, but a port node may not have sub-ports!
     7.5  
     7.6  //This uses require.js to create a module.  This module has the name of the
     7.7 -// file (POPDisplay).  Inside the define, a number of data structures and 
     7.8 +// file (<currFileName>).  Inside the define, a number of data structures and 
     7.9  // functions are created, then returned at the end.  The returned things are
    7.10  // what can be accessed by external functions that load this module, via
    7.11 -// themselves using the require("POPDisplay") call
    7.12 -define(function(require, exports, module) {
    7.13 +// themselves using the require("<currFileName>") call
    7.14 +
    7.15 +
    7.16 +//The syntax graph is being modified to include visualization information.
    7.17 +//It may be cleaner to store visualization information separately, but it
    7.18 +// turns out to be more convenient to place the visual info directly with
    7.19 +// the thing visualized.
    7.20 +//Will need to provide a means for each viewer to have their own separate
    7.21 +// view information.  Also need a means for creating a default view that
    7.22 +// a particular person's state gets reset to when others have modified
    7.23 +// the graph too far for their old view info to make sense anymore..
    7.24 +//This is a bit of a messy problem!  Making the view always fully dynamic,
    7.25 +// computed on the fly would solve the issues, but it would take away the
    7.26 +// programmer's experience of being able to tune the view to their preference.
    7.27 +//So, for now, until get more experience and get deeper into this, just 
    7.28 +// making all the view info be attached to the nodes as the graph is 
    7.29 +// constructed.  The system guesses a placemnt, then it is up to the user
    7.30 +// to move things around to suit their preference.  The movement can be 
    7.31 +// automated later..  simplest approach for now is make all placement 
    7.32 +// manual and save the placement inside the graph.  But will at least
    7.33 +// make the info be stored in an array indexed by user (separately
    7.34 +// hash user-name which looks up the index of that user-name. Recycle indexes)
    7.35 +define( function(require, exports, module) {
    7.36  
    7.37  //this is the top level handle to the syntax graph of the gabe transform rule
    7.38  var firstGabeTransformRule = {};
    7.39  
    7.40 -//make a variable that holds an empty element struct.. this var will used
    7.41 +//make a variable that holds an empty element struct.. this var will be used
    7.42  // to build up an element, and then reused to build up other elements 
    7.43  var tempElem = 
    7.44   { properties: [],
    7.45     portsIn:    [],
    7.46     portsOut:   [],
    7.47 -   subElems:   []
    7.48 +   subElems:   [],
    7.49 +   viewInfo:   []
    7.50   };
    7.51   
    7.52 +
    7.53 +//tempElem.viewInfo = {};
    7.54 +
    7.55  //the root of the Gabe Transform to the temp elem, then build up a property
    7.56  // to place into the elem.
    7.57  firstGabeTransformRule.root = tempElem; 
    7.58 @@ -29,7 +54,8 @@
    7.59  var tempProperty = 
    7.60   { propertyName: "TypeOfElement",
    7.61     propertyValue: "GabeTransformRule",
    7.62 -   subProperties: []
    7.63 +   subProperties: [],
    7.64 +   viewInfo:      []
    7.65   }
    7.66   
    7.67  //attach it to the root elem
    7.68 @@ -39,7 +65,8 @@
    7.69  var tempProperty = 
    7.70   { propertyName: "TypeOfSyntacticStructure",
    7.71     propertyValue: "syntacticHierarchy",
    7.72 -   subProperties: []
    7.73 +   subProperties: [],
    7.74 +   viewInfo:      []
    7.75   }
    7.76  
    7.77  firstGabeTransformRule.root.properties[1] = tempProperty;
    7.78 @@ -49,15 +76,17 @@
    7.79   { properties: [],
    7.80     portsIn:    [],
    7.81     portsOut:   [],
    7.82 -   subElems:   []
    7.83 +   subElems:   [],
    7.84 +   viewInfo:   []
    7.85   }
    7.86  
    7.87  firstGabeTransformRule.root.subElems[0] = tempElem;
    7.88  
    7.89  var tempProperty = 
    7.90 - { propertyName: "TypeOfElement",
    7.91 + { propertyName:  "TypeOfElement",
    7.92     propertyValue: "GabeQueryPattern",
    7.93 -   subProperties: []
    7.94 +   subProperties: [],
    7.95 +   viewInfo:      []
    7.96   }
    7.97   
    7.98  tempElem.properties[0] = tempProperty;
    7.99 @@ -65,7 +94,8 @@
   7.100  var tempProperty =
   7.101   { propertyName: "TypeOfSyntacticStructure",
   7.102     propertyValue: "syntacticHierarchy",
   7.103 -   subProperties: []
   7.104 +   subProperties: [],
   7.105 +   viewInfo:      []
   7.106   }
   7.107    
   7.108  tempElem.properties[1] = tempProperty;
   7.109 @@ -77,7 +107,8 @@
   7.110   { properties: [],
   7.111     portsIn:    [],
   7.112     portsOut:   [],
   7.113 -   subElems:   []
   7.114 +   subElems:   [],
   7.115 +   viewInfo:   []
   7.116   }
   7.117  
   7.118  firstGabeTransformRule.root.subElems[1] = tempElem;
   7.119 @@ -85,7 +116,8 @@
   7.120  var tempProperty = 
   7.121   { propertyName: "TypeOfElement",
   7.122     propertyValue: "GabeReplacePattern",
   7.123 -   subProperties: []
   7.124 +   subProperties: [],
   7.125 +   viewInfo:      []
   7.126   }
   7.127   
   7.128  tempElem.properties[0] = tempProperty;
   7.129 @@ -93,7 +125,8 @@
   7.130  var tempProperty =
   7.131   { propertyName: "TypeOfSyntacticStructure",
   7.132     propertyValue: "syntacticHierarchy",
   7.133 -   subProperties: []
   7.134 +   subProperties: [],
   7.135 +   viewInfo:      []
   7.136   }
   7.137    
   7.138  tempElem.properties[1] = tempProperty;

     8.1 --- a/1__Development/0__Code_Dev/Javascript_approach/Display/app/renderPOPSyntaxGraph.js	Sun Jul 06 12:02:12 2014 -0700
     8.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/Display/app/renderPOPSyntaxGraph.js	Wed Jul 23 18:51:15 2014 -0700
     8.3 @@ -11,9 +11,8 @@
     8.4  	
     8.5      var mainContext = Engine.createContext();
     8.6  	
     8.7 -	var boxSVG1 = '<svg width="55" height="55"><rect x="2" y="2" rx="20" ry="20" width="50" height="50" style="fill:none;stroke:black;stroke-width:5;opacity:1">';
     8.8  	var boxSVG = [];
     8.9 -	boxSVG[1] = '<svg width="';
    8.10 +	boxSVG[1] = '<svg width="'; //start at 1!  makes things simpler..
    8.11  	boxSVG[2] = '" height="';
    8.12  	boxSVG[3] = '"><rect x="';
    8.13  	boxSVG[4] = '" y="';
    8.14 @@ -56,16 +55,19 @@
    8.15              overflow: 'hidden'
    8.16          }
    8.17      });
    8.18 +	var retRootBox = {
    8.19 +		ID: "retRootBox",
    8.20 +		width: elem1Container.size[0],
    8.21 +		height: elem1Container.size[1],
    8.22 +		shape: null
    8.23 +	}
    8.24 +
    8.25  	
    8.26  //==
    8.27  //	1:width 2:height 3:x 4:y 5:rx 6:ry 7:width 8:height 9:fill 10:stroke
    8.28  //  11:stroke-width 12:opacity
    8.29 -	var box1_1width = 66;
    8.30 -	var box1_1height = 86
    8.31 -//	var boxSVGFromParts1_1 = boxSVG[1] + (box1_1width + 2) + boxSVG[2] + (box1_1height + 2) + boxSVG[3] + '1' + boxSVG[4] + '1' + boxSVG[5] + '20' + boxSVG[6] + '20' + boxSVG[7] + box1_1width + boxSVG[8] + box1_1height + boxSVG[9] + 'none' + boxSVG[10] + 'red' + boxSVG[11] + '2' + boxSVG[12] + '1' + boxSVG[13];
    8.32  	var box1_1w = 66; var box1_1h = 86; var box1_1pad = 2;
    8.33  	var boxSVGFromParts1_1 = boxSVG[1] + (box1_1w + box1_1pad) + boxSVG[2] + (box1_1h + box1_1pad) + boxSVG[3] + '1' + boxSVG[4] + '1' + boxSVG[5] + '20' + boxSVG[6] + '20' + boxSVG[7] + box1_1w + boxSVG[8] + box1_1h + boxSVG[9] + 'none' + boxSVG[10] + 'red' + boxSVG[11] + '2' + boxSVG[12] + '1' + boxSVG[13];
    8.34 -	function getElemBox(){ return boxSVGFromParts1_1 };
    8.35  
    8.36  //== elem1 box 1 --> box1_1
    8.37  	var box1_1 = new Surface({
    8.38 @@ -78,6 +80,15 @@
    8.39          transform: Transform.translate(box1_1x, box1_1y, 0)
    8.40      });
    8.41  
    8.42 +	var retElemBox = {
    8.43 +		ID: "retElemBox",
    8.44 +		x: box1_1x,
    8.45 +		y: box1_1y,
    8.46 +		width: box1_1w + box1_1pad, //outside of SVG BBox NOT shape in box
    8.47 +		height: box1_1h + box1_1pad,
    8.48 +		shape: boxSVGFromParts1_1
    8.49 +	}
    8.50 +
    8.51  	//Below, calculate a bezier curve that is anchored at the end of such
    8.52  	// text, so need the bounding box of a text element..  to do so, must 
    8.53  	// first render the text!  That appears to be the only way to calculate
    8.54 @@ -108,7 +119,7 @@
    8.55  	//now set the SVG text string -- from this point down can be repeated 
    8.56  	// for multiple strings without removing or re-adding the element, nor
    8.57  	// fiddling with the DOM
    8.58 -	var text1_1_1_SVG = '<svg>  <text x="0" y="0" style="font-family: Arial; font-size: 12;fill:none;stroke:none" id="svgText">' + text1_1_1.content + '</text> </svg>';
    8.59 +	var text1_1_1_SVG = '<svg>  <text x="0" y="9" style="font-family: Arial; font-size: 11;fill:black;stroke:none" id="svgText">' + text1_1_1.content + '</text> </svg>';
    8.60  	//note that id is inside the text element! Also the fill and stroke are
    8.61  	// null so that nothing paints
    8.62  	el1.innerHTML = text1_1_1_SVG; 
    8.63 @@ -121,6 +132,7 @@
    8.64  	console.log("svgText width: " + rect.width + " right: " + rect.right);
    8.65  	
    8.66  	var retText1_1_1 = {
    8.67 +		ID: "retText1_1_1",
    8.68  		width: rect.width,
    8.69  		height: rect.height,
    8.70  		shape: text1_1_1_SVG
    8.71 @@ -130,20 +142,18 @@
    8.72  	  size: [true, true],
    8.73        content: "portsIn",
    8.74        properties: {
    8.75 -        color: 'black',
    8.76 -        textAlign: 'left',
    8.77 -        fontSize: '11px',
    8.78          cursor: 'pointer'
    8.79        }
    8.80  	});	
    8.81  	//repeat for the next text surface
    8.82 -	var text1_1_2_SVG = '<svg>  <text x="0" y="0" style="font-family: Arial; font-size: 12;fill:none;stroke:none" id="svgText">' + text1_1_2.content + '</text> </svg>';
    8.83 +	var text1_1_2_SVG = '<svg>  <text x="0" y="9" style="font-family: Arial; font-size: 11;fill:black;stroke:none" id="svgText">' + text1_1_2.content + '</text> </svg>';
    8.84  	el1.innerHTML = text1_1_2_SVG; 
    8.85  	var gottenElem = document.getElementById("svgText");
    8.86      var rect = gottenElem.getBoundingClientRect();
    8.87  	console.log("svgText: " + gottenElem.textContent + " width: " + rect.width + " right: " + rect.right);
    8.88  	
    8.89  	var retText1_1_2 = {
    8.90 +		ID: "retText1_1_2",
    8.91  		width: rect.width,
    8.92  		height: rect.height,
    8.93  		shape: text1_1_2_SVG
    8.94 @@ -160,13 +170,14 @@
    8.95        }
    8.96  	});
    8.97  	//repeat for the next text surface
    8.98 -	var text1_1_3_SVG = '<svg>  <text x="0" y="0" style="font-family: Arial; font-size: 12;fill:none;stroke:none" id="svgText">' + text1_1_3.content + '</text> </svg>';
    8.99 +	var text1_1_3_SVG = '<svg>  <text x="0" y="9" style="font-family: Arial; font-size: 11;fill:black;stroke:none" id="svgText">' + text1_1_3.content + '</text> </svg>';
   8.100  	el1.innerHTML = text1_1_3_SVG; 
   8.101  	var gottenElem = document.getElementById("svgText");
   8.102      var rect = gottenElem.getBoundingClientRect();
   8.103  	console.log("svgText: " + gottenElem.textContent + " width: " + rect.width + " right: " + rect.right);
   8.104  	
   8.105  	var retText1_1_3 = {
   8.106 +		ID: "retText1_1_3",
   8.107  		width: rect.width,
   8.108  		height: rect.height,
   8.109  		shape: text1_1_3_SVG
   8.110 @@ -183,13 +194,14 @@
   8.111       }
   8.112  	});
   8.113  	//repeat for the next text surface
   8.114 -	var text1_1_4_SVG = '<svg>  <text x="0" y="0" style="font-family: Arial; font-size: 12;fill:none;stroke:none" id="svgText">' + text1_1_4.content + '</text> </svg>';
   8.115 +	var text1_1_4_SVG = '<svg>  <text x="0" y="9" style="font-family: Arial; font-size: 11;fill:black;stroke:none" id="svgText">' + text1_1_4.content + '</text> </svg>';
   8.116  	el1.innerHTML = text1_1_4_SVG; 
   8.117  	var gottenElem = document.getElementById("svgText");
   8.118      var rect = gottenElem.getBoundingClientRect();
   8.119  	console.log("svgText: " + gottenElem.textContent + " width: " + rect.width + " right: " + rect.right);
   8.120  	
   8.121  	var retText1_1_4 = {
   8.122 +		ID: "retText1_1_4",
   8.123  		width: rect.width,
   8.124  		height: rect.height,
   8.125  		shape: text1_1_4_SVG
   8.126 @@ -202,19 +214,19 @@
   8.127  	var textMod1_1_1_1 = new StateModifier({
   8.128          transform: Transform.translate(text1_1_1x, text1_1_1y, 0)
   8.129      });
   8.130 -	text1_1_1_SVG.x = 8; text1_1_1_SVG.y = 0; //subtract box x & y
   8.131 +	retText1_1_1.x = 8; retText1_1_1.y = 8; //subtract box x & y
   8.132  	var textMod1_1_2_1 = new StateModifier({
   8.133          transform: Transform.translate(8, 25, 0)
   8.134      });
   8.135 -	text1_1_2_SVG.x = 8; text1_1_2_SVG.y = 23; //subtract box x & y
   8.136 +	retText1_1_2.x = 8; retText1_1_2.y = 23; //subtract box x & y
   8.137  	var textMod1_1_3_1 = new StateModifier({
   8.138          transform: Transform.translate(8, 42, 0)
   8.139      });
   8.140 -	text1_1_3_SVG.x = 8; text1_1_3_SVG.y = 40; //subtract box x & y
   8.141 +	retText1_1_3.x = 8; retText1_1_3.y = 40; //subtract box x & y
   8.142  	var textMod1_1_4_1 = new StateModifier({
   8.143          transform: Transform.translate(8, 59, 0)
   8.144      });
   8.145 -	text1_1_4_SVG.x = 8; text1_1_4_SVG.y = 57; //subtract box x & y
   8.146 +	retText1_1_4.x = 8; retText1_1_4.y = 57; //subtract box x & y
   8.147  //==
   8.148  	elem1Container.add(boxMod1_1_1).add(box1_1);
   8.149  	elem1Container.add(textMod1_1_1_1).add(text1_1_1);
   8.150 @@ -227,9 +239,7 @@
   8.151  //  11:stroke-width 12:opacity
   8.152  	var box1_2w = 183; var box1_2h = 69; var box1_2pad = 2;
   8.153  	var boxSVGFromParts1_2 = boxSVG[1] + (box1_2w + box1_2pad) + boxSVG[2] + (box1_2h + box1_2pad) + boxSVG[3] + '1' + boxSVG[4] + '1' + boxSVG[5] + '20' + boxSVG[6] + '20' + boxSVG[7] + box1_2w + boxSVG[8] + box1_2h + boxSVG[9] + 'none' + boxSVG[10] + 'green' + boxSVG[11] + '2' + boxSVG[12] + '1' + boxSVG[13];
   8.154 -	
   8.155 -	function getPropertiesBox(){ return boxSVGFromParts1_2 };
   8.156 -	
   8.157 +		
   8.158  	var box1_2 = new Surface({
   8.159  	  size: [true, true],
   8.160        content: boxSVGFromParts1_2
   8.161 @@ -239,6 +249,15 @@
   8.162  	var boxMod1_2_1 = new StateModifier({
   8.163          transform: Transform.translate(box1_2x, box1_2y, 0)
   8.164      });
   8.165 +	var retPropertiesBox = {
   8.166 +		ID: "retPropertiesBox",
   8.167 +		x: box1_2x,
   8.168 +		y: box1_2y,
   8.169 +		width: box1_2w + box1_2pad, //think should be 2*pad!
   8.170 +		height: box1_2h + box1_2pad,
   8.171 +		shape: boxSVGFromParts1_2
   8.172 +	}
   8.173 +
   8.174  //== elem 1 box 2 text 1 --> text1_2_1
   8.175  	var text1_2_1 = new Surface({
   8.176  	  size: [true, true],
   8.177 @@ -251,12 +270,13 @@
   8.178        }
   8.179  	});
   8.180  	//repeat for the next text surface
   8.181 -	var text1_2_1_SVG = '<svg>  <text x="0" y="0" style="font-family: Arial; font-size: 12;fill:blue;stroke:none" id="svgText">' + text1_2_1.content + '</text> </svg>';
   8.182 +	var text1_2_1_SVG = '<svg>  <text x="0" y="9" style="font-family: Arial; font-size: 11;fill:black;stroke:none" id="svgText">' + text1_2_1.content + '</text> </svg>';
   8.183  	el1.innerHTML = text1_2_1_SVG; 
   8.184  	var gottenElem = document.getElementById("svgText");
   8.185      var rect = gottenElem.getBoundingClientRect();
   8.186  	console.log("svgText: " + gottenElem.textContent + " width: " + rect.width + " right: " + rect.right);	
   8.187  	var retText1_2_1 = {
   8.188 +		ID: "retText1_2_1",
   8.189  		width: rect.width,
   8.190  		height: rect.height,
   8.191  		shape: text1_2_1_SVG
   8.192 @@ -274,52 +294,52 @@
   8.193        }
   8.194  	});
   8.195  	//repeat for the next text surface
   8.196 -	var text1_2_2_SVG = '<svg>  <text x="0" y="0" style="font-family: Arial; font-size: 12;fill:red;stroke:none" id="svgText">' + text1_2_2.content + '</text> </svg>';
   8.197 +	var text1_2_2_SVG = '<svg>  <text x="0" y="9" style="font-family: Arial; font-size: 11;fill:black;stroke:none" id="svgText">' + text1_2_2.content + '</text> </svg>';
   8.198  	el1.innerHTML = text1_2_2_SVG; 
   8.199 +//	document.body.appendChild(el1);
   8.200  	var gottenElem = document.getElementById("svgText");
   8.201      var rect = gottenElem.getBoundingClientRect();
   8.202  	console.log("svgText: " + gottenElem.textContent + " width: " + rect.width + " right: " + rect.right);	
   8.203  	var retText1_2_2 = {
   8.204 +		ID: "retText1_2_2",
   8.205  		width: rect.width,
   8.206  		height: rect.height,
   8.207  		shape: text1_2_2_SVG
   8.208  	}
   8.209  
   8.210 -	var text1_2_3 = new Surface({
   8.211 -	  size: [true, true],
   8.212 -      content: "subProperties",
   8.213 -      properties: {
   8.214 -        color: 'black',
   8.215 -        textAlign: 'left',
   8.216 -        fontSize: '11px',
   8.217 -        cursor: 'pointer'
   8.218 -      }
   8.219 -	});
   8.220  	//repeat for the next text surface
   8.221 -	var text1_2_3_SVG = '<svg id="svgTextHolder">  <text x="0" y="0" style="font-family: Arial; font-size: 12;fill:none;stroke:none" id="svgText">' + text1_2_3.content + '</text> </svg>';
   8.222 +	var text1_2_3_SVG = '<svg id="svgTextHolder">  <text x="0" y="9" style="font-family: Arial; font-size: 11;fill:black;stroke:none" id="svgText">' + 'subProperties' + '</text> </svg>';
   8.223  	el1.innerHTML = text1_2_3_SVG; 
   8.224 +//	document.body.appendChild(el1);
   8.225  	var gottenElem = document.getElementById("svgText");
   8.226 +//	gottenElem.parentNode.replaceChild(el1, el1); 
   8.227 +	
   8.228      var rect = gottenElem.getBoundingClientRect();
   8.229  	console.log("svgText: " + gottenElem.textContent + " width: " + rect.width + " right: " + rect.right);	
   8.230  	var retText1_2_3 = {
   8.231 +		ID: "retText1_2_3",
   8.232  		width: rect.width,
   8.233  		height: rect.height,
   8.234  		shape: text1_2_3_SVG
   8.235  	}
   8.236 +	var text1_2_3 = new Surface({
   8.237 +	  size: [rect.width, rect.height],
   8.238 +      content: text1_2_3_SVG
   8.239 +	});
   8.240  
   8.241  //==
   8.242  	var textMod1_2_1_1 = new StateModifier({
   8.243          transform: Transform.translate(108, 8, 0)
   8.244      });
   8.245 -	text1_2_1_SVG.x = 8; text1_2_1_SVG.y = 6; //subtract box x & y
   8.246 +	retText1_2_1.x = 8; retText1_2_1.y = 6; //subtract box x & y
   8.247  	var textMod1_2_2_1 = new StateModifier({
   8.248          transform: Transform.translate(108, 25, 0)
   8.249      });
   8.250 -	text1_2_2_SVG.x = 8; text1_2_2_SVG.y = 23; //subtract box x & y
   8.251 +	retText1_2_2.x = 8; retText1_2_2.y = 23; //subtract box x & y
   8.252  	var textMod1_2_3_1 = new StateModifier({
   8.253          transform: Transform.translate(108, 42, 0)
   8.254      });
   8.255 -	text1_2_3_SVG.x = 8; text1_2_3_SVG.y = 40; //subtract box x & y
   8.256 +	retText1_2_3.x = 8; retText1_2_3.y = 40; //subtract box x & y
   8.257  //==
   8.258  	elem1Container.add(boxMod1_2_1).add(box1_2);
   8.259  	elem1Container.add(textMod1_2_1_1).add(text1_2_1);
   8.260 @@ -350,11 +370,14 @@
   8.261  	// right edge of the "properties" text in the left box, and to the
   8.262  	// middle of the left side of the right box
   8.263  	var bezPoints = [{},{}];
   8.264 -	var fontSz = 11;
   8.265 -	bezPoints[0].x = box1_1x + box1_1w;
   8.266 -	bezPoints[0].y = text1_1_1y + fontSz/2 + 8;
   8.267 -	bezPoints[1].x = box1_2x;
   8.268 -	bezPoints[1].y = box1_2y + (box1_2h+box1_2pad)/2;
   8.269 +	var bezOrigin = {
   8.270 +		x: box1_1x + retText1_1_1.width + retText1_1_1.x,
   8.271 +		y: text1_1_1y + retText1_1_1.height/2 + 3
   8.272 +	}
   8.273 +	bezPoints[0].x = 0;
   8.274 +	bezPoints[0].y = 0;
   8.275 +	bezPoints[1].x = box1_2x - bezOrigin.x;
   8.276 +	bezPoints[1].y = box1_2y + (box1_2h+box1_2pad)/2 - bezOrigin.y;
   8.277  
   8.278  	var controlPoints = [];
   8.279  	controlPoints[0] = {x:bezPoints[1].x, y:bezPoints[0].y};
   8.280 @@ -363,11 +386,14 @@
   8.281  
   8.282  	//	1:width 2:height 3:st x 4:st y 5:c1 x 6:c1 y 7:c2 x 8:c2 y 9: end x
   8.283  	// 10: end y 11:fill 12:stroke 13:stroke-width 14:opacity
   8.284 +	var bezWidth = (bezPoints[1].x - bezPoints[0].x + 4); //add 2x stroke 
   8.285 +	var bezHeight = (bezPoints[1].y - bezPoints[0].y + 4); //add 2x stroke
   8.286 +	console.log("bez width: " + bezWidth + " and height: " + bezHeight);
   8.287  	var bezSVG1 = "";
   8.288 -	bezSVG1 += bezSVG[1] + 200;//(bezPoints[1].x - bezPoints[0].x + 6);
   8.289 -	bezSVG1 += bezSVG[2] + 200;//(bezPoints[0].y - bezPoints[1].y + 6);
   8.290 -	bezSVG1 += bezSVG[3] + bezPoints[0].x; 
   8.291 -	bezSVG1 += bezSVG[4] + bezPoints[0].y; 
   8.292 +	bezSVG1 += bezSVG[1] + bezWidth;
   8.293 +	bezSVG1 += bezSVG[2] + bezHeight;
   8.294 +	bezSVG1 += bezSVG[3] + (bezPoints[0].x + 2); //move by stroke width
   8.295 +	bezSVG1 += bezSVG[4] + (bezPoints[0].y + 2); //move by stroke width
   8.296  	bezSVG1 += bezSVG[5] + controlPoints[0].x;
   8.297  	bezSVG1 += bezSVG[6] + controlPoints[0].y;
   8.298  	bezSVG1 += bezSVG[7] + controlPoints[1].x;
   8.299 @@ -380,8 +406,20 @@
   8.300  	  size: [true, true],
   8.301        content: bezSVG1
   8.302   	});
   8.303 +	var bezMod = new StateModifier({
   8.304 +        transform: Transform.translate(bezOrigin.x, bezOrigin.y, 0)
   8.305 +    });
   8.306  
   8.307 -	elem1Container.add(bez1_1);
   8.308 +	elem1Container.add(bezMod).add(bez1_1);
   8.309 +	
   8.310 +	var retBezier = {
   8.311 +		ID: "bezier",
   8.312 +		x: bezOrigin.x,
   8.313 +		y: bezOrigin.y,
   8.314 +		width: bezWidth,
   8.315 +		height: bezHeight,
   8.316 +		shape: bezSVG1
   8.317 +	}
   8.318  
   8.319  //for some reason, the way use el1 above makes the DOM stop rendering
   8.320  // So, in order to get these other elements to render, first remove
   8.321 @@ -393,7 +431,7 @@
   8.322  var el2 =  document.createElement("span")
   8.323  var displayStr = bezSVG1.replace(/</g, "&lt");//make the html display as text
   8.324  el2.innerHTML = (displayStr + "<br>");
   8.325 -document.body.appendChild(el2);
   8.326 +//document.body.appendChild(el2);
   8.327  console.log("bez svg: " + bezSVG1);
   8.328  
   8.329  //== elem 1 Modifer 1 --> contMod1_1
   8.330 @@ -406,17 +444,19 @@
   8.331  //==
   8.332  
   8.333  	//cause this all to be painted, by adding to the main context
   8.334 -	mainContext.add(contMod1_1).add(contMod1_2).add(elem1Container);
   8.335 +//	mainContext.add(contMod1_1).add(contMod1_2).add(elem1Container);
   8.336  	
   8.337  	return {
   8.338 -		getElemBox: getElemBox,
   8.339 +		getRootBox: retRootBox,
   8.340 +		getElemBox: retElemBox,
   8.341  		getText1_1_1: retText1_1_1,
   8.342  		getText1_1_2: retText1_1_2,
   8.343  		getText1_1_3: retText1_1_3,
   8.344  		getText1_1_4: retText1_1_4,
   8.345 -		getPropertiesBox: getPropertiesBox,
   8.346 +		getPropertiesBox: retPropertiesBox,
   8.347  		getText1_2_1: retText1_2_1,
   8.348  		getText1_2_2: retText1_2_2,
   8.349 -		getText1_2_3: retText1_2_3
   8.350 +		getText1_2_3: retText1_2_3,
   8.351 +		getBezier: retBezier
   8.352  	}
   8.353  });

     9.1 --- a/1__Development/0__Code_Dev/Javascript_approach/ToDos__14_Jy_02.txt	Sun Jul 06 12:02:12 2014 -0700
     9.2 +++ b/1__Development/0__Code_Dev/Javascript_approach/ToDos__14_Jy_02.txt	Wed Jul 23 18:51:15 2014 -0700
     9.3 @@ -32,7 +32,7 @@
     9.4  
     9.5  #-] Get famous working without a net connection -- download whatever URLs that the page references, so are local files.
     9.6  
     9.7 --] Get famous fonts -- download to local somehow..
     9.8 +XXX -] Get famous fonts -- download to local somehow..
     9.9  
    9.10  #-] Figure out how that other graph drawing thing made the curvy arrow-lines between nodes..
    9.11  
    9.12 @@ -44,28 +44,30 @@
    9.13  [-] Were also doing a hierarchy of bounding boxes
    9.14  [-] Were parsing the syntax graph -- generate a bounding box and visual contents for each kind of element in the syntax graph
    9.15  
    9.16 --] Next, define a data structure for the visual elements.
    9.17 -- -] within it is the information needed to construct the graph that have drawn
    9.18 -- -] see below for visual element design.. and #look back over java version..
    9.19 +#-] Next, define a data structure for the visual elements.
    9.20 +#- -] within it is the information needed to construct the graph that have drawn
    9.21 +#- -] see below for visual element design.. and #look back over java version..
    9.22  
    9.23 --] Next, take the syntax graph for the GabePatterns, create the visual elements to represent that.
    9.24 +#-] Next, take the syntax graph for the GabePatterns, create the visual elements to represent that.
    9.25  
    9.26 --] Next, write the Display object to receive the visual elements, and then create the famous objects from it, which end up painting the syntax graph elements as seen in the PDF.
    9.27 +#-] Next, write the Display object to receive the visual elements, and then create the famous objects from it, which end up painting the syntax graph elements as seen in the PDF.
    9.28  
    9.29 --] Next, create the visual element objects for the rest of the syntax graph, and have them all draw to the screen, using famous.
    9.30 +#-] Next, create the visual element objects for the rest of the syntax graph, and have them all draw to the screen, using famous.
    9.31  
    9.32 --] Make a Display object, which contains the code wrote above.
    9.33 +#-] Make a Display object, which contains the code wrote above.
    9.34  
    9.35 --] Have the Display object receive the visual element object, and proceed to draw it to the screen using famous.  Choose a protocol for handing visual element objects to the Display and triggering the Display to render them via famous.
    9.36 +#-] Have the Display object receive the visual element object, and proceed to draw it to the screen using famous.  Choose a protocol for handing visual element objects to the Display and triggering the Display to render them via famous.
    9.37  
    9.38 --] Make the visual elements for a graph of 5 nodes.  hand them to the display.
    9.39 +#-] Make the visual elements for a graph of 5 nodes.  hand them to the display.
    9.40  
    9.41 --] Make a "change" visual element.  Have the display modify its famous structure according to the change visual element.
    9.42 +XXX -] Make a "change" visual element.  Have the display modify its famous structure according to the change visual element.
    9.43 +[-] Famous can't do this!  Just send a new visual hierarchy and render the whole thing
    9.44  
    9.45 +//================  Visualizer =================
    9.46  
    9.47 --] Separately, the task is to construct a visual hierarchy structure inside the visualizer..  then to convert that into visual elements..  then to receive those elements in the famous display, and reconstruct a famous structure from the stream of visual elements.
    9.48 +-] Separately, the task is to construct a visual hierarchy structure inside the visualizer..  then to convert that into visual elements..  #( this part  done) receive those elements in the famous display, and reconstruct a famous structure from the stream of visual elements.
    9.49  
    9.50 --] Create a source holder object.. just a simple thing, as a place holder
    9.51 +#-] Create a source holder object.. just a simple thing, as a place holder
    9.52  
    9.53  -] dump the syntax graph wrote for Gabe out to a JSON file
    9.54  
    9.55 @@ -73,11 +75,11 @@
    9.56  
    9.57  -] Then, make a new object, just one syntax graph element, as above.  Send it to a JSON file.  Have the source holder read it in and convert to javascript object.
    9.58  
    9.59 --] make a visualizer object inside the source holder
    9.60 +#-] make a visualizer object inside the source holder
    9.61  
    9.62 --] give the visualizer access to the data structure inside the holder, which is the syntax graph
    9.63 +#-] give the visualizer access to the data structure inside the holder, which is the syntax graph
    9.64  
    9.65 --] have the visualizer build its own data structure?  Or augment the existing one with new stuff?  Add a visualizer field to all of the syntax graph nodes?  Make it an array, one spot for each visualizer added to the source holder?
    9.66 +-] have the visualizer build its own data structure?  Or augment the existing one with new visual related stuff?  Add a visualizer field to all of the syntax graph nodes?  Make it an array, one spot for each visualizer added to the source holder?
    9.67  
    9.68  -] Go with augment for now, even though feels like it's mixing things dangerously..  it, on the other hand, puts the visualization right into the data visualized, so keeps the two in sync -- no danger of something modifying the data behind the back of the visualizer..
    9.69  
    9.70 @@ -85,89 +87,99 @@
    9.71  
    9.72  -] have the visualizer generate a visual element object from that simple graph.
    9.73  
    9.74 --] have the visualizer send that visual element to the display created above, which 
    9.75 -
    9.76 --] Draw the visual hierarchy structure, which is separate from the syntax graph data.  Perhaps make them both the same data structures, just add visual objects as properties (which are ignored by everything thing else, like the compiler)
    9.77 +-] have the visualizer send that visual element to the display created above
    9.78  
    9.79  -] The javascript structure of linked objects will be internal to the source holder.  The visualizer will take that and construct stream of visual elements from it.  The modifier will directly modify it.  The holder will also have a serialized version of the data structure -- which is JSON format.  The data structure will be made such that can use the JSON tools to directly turn it into JSON, save that to a file, then later read the file back, and use the JSON tool to parse the JSON back into the javascript linked objects.
    9.80  
    9.81  -] The modifier will attach additional objects and properties, which are used to manage interaction with something that is editing the source..  for example, an insertion point is maintained, and highlight markings, and selection markings.  (maybe multiple selections, and even browse through previous selections, and fork off one)
    9.82  
    9.83 --] The modifier will notify the visualizer of what changed, each time it does a change.  The visualizer can then decide what needs to be re-sent to the display, and can decide new visual placements of things, if needed..
    9.84 +-] The modifier will notify the visualizer, somehow, of what changed, each time it does a change.  The visualizer can then decide what needs to be sent to the display, and can decide new visual placements of things, if needed.. (thinking maybe have delimiters in the graph, that mark the boundaries of what is being visualized, and act as anchor points for pulling in things from off-screen..)
    9.85  
    9.86 +//=================  From graph to placement and size  ==================
    9.87 +//
    9.88 +//=======================================================================
    9.89 +Given a syntax graph, need an algorithm for deciding what are the local contexts, building up the hierarchy, and positioning each element inside a given context, and scaling that context relative to its parent (all siblings should have the same scale).
    9.90  
    9.91 -==============================================
    9.92 +Okay..  first, have connections between different graph elements..  want connected things to be visually close..  second, want to include user-specified hierarchy, so entire sub-graphs can be tagged as one "unit" -- the equivalent of a function -- such units can be re-used in multiple places..
    9.93 +
    9.94 +Will need different view annotations for each place the function is used..  so, maybe add typed properties to the original, where each type says which reference it pertains to..  so each reference can have different view arrangements..  Or, maybe, 
    9.95 +
    9.96 +//==
    9.97 +
    9.98 +Okay, what about this..  place annotations, by hand, onto the syntax graph objects..  those state placement relative to each other, and state visual hierarchy, and state scale relative to each other..  then, the current view is like a projection onto the graph, that selects which elements are within the view, and sets a global zoom.
    9.99 +
   9.100 +You know, pretty much want to build the view hierarchy as part of the syntax graph..  will need visual hierarchy, including bounding boxes, in order to calculate what is (potentially) visible to the camera, and when go to 3D, will need hierarchy in order to know things like what to represent as a single box, versus to break open and show the innards..  and hierarchy will decide relative scale to each other -- siblings at same scale as each other, and parents at larger scale than children, and once scaled small enough, stop showing children, which are the innards, instead just show the parent as a box.  Also will want hierarchy during projection from 3D onto the camera's view..  hierarchy will affect placement within 3rd dimension..
   9.101 +
   9.102 +Will, at some point, want topological visualization, which represents translations between worlds..  represents the twist-upon-itself topology of many types of thought..  the thing where, when think about some system, there are relationships among things such that part of thought moves within one "system" or one "universe" and then a transition happens to a different system/universe after which have relationships within that one, then switch again..
   9.103 +
   9.104 +=========================================================
   9.105 +==
   9.106 +==
   9.107 +==
   9.108 +==========================================================
   9.109 +
   9.110 +-] attach the view hierarchy to the syntax graph itself
   9.111 +- -] The Display receives pointer to the hierarchy, but it is embedded within the syntax graph, as an extra field that exists in every node, but the field is not visualized.
   9.112 +
   9.113 +-] make the Visualizer attach a handler fn to each bounding box
   9.114 +- -] test that the smallest bounding box is what receives the event 
   9.115 +- -] place parent links into each bounding box in the view hierarchy
   9.116 +
   9.117 +-] make the Display register a Famous event on each surface that corresponds to a bounding box
   9.118 +- -] make the Display put a back-link in each surface that points to the view hierarchy bounding box that the surface corresponds to
   9.119 +- -] when register the event, register the generic Display event-handler
   9.120 +
   9.121 +-] make a generic-event-handler, which is part of the Display code
   9.122 +- -] it receives the event object
   9.123 +- -] it takes the surface out of the event object
   9.124 +- -] it uses the back-link in the surface to get the view hierarchy object
   9.125 +- -] it calls the handler function attached to the view hierarchy object
   9.126 +
   9.127 +-] make a handler for key presses.
   9.128 +- -] the handler receive the event object, plus the smallest enclosing bounding box.
   9.129 +
   9.130 +-] make the gesture-handler turn the event plus bounding box into a command.
   9.131 +
   9.132 +For example, if previously a gesture caused the start of the mode for typing text into a field -- say for entering the name of a variable -- then the gesture handler looks that up, within state enclosed with the gesture handler but shareable among different handlers.  The code then branches to where it extracts the key value from the event object.  It reuses a "key into field" command object, and packs it with data.  The data includes the model-object that is attached to the appropriate bounding box (the handler does the work of figuring out which bounding box corresponds to the syntax graph object that owns the field that is being typed into).  So, each bounding box has a back-link to the Model object that the shape inside the bounding box represents, where appropriate (IE, the bounding box for text has no back-link, but the bounding box for the element-box shape does have a back-link to the element object!)  Might make it just "useful info" -- for example, a text bounding box might include the name of the field of the object that the larger enclosing bounding box back-links to.  The gesture-handler will also extract any needed info from the event object, such as which key was pressed, and add that to the command-object.
   9.133 +
   9.134 +The command is then sent to the Modifier, which changes the back-linked-to syntax graph objects.  As part of that, it also modifies the visualized-sub-graph, and notifies the visualizer to update.
   9.135 +
   9.136 +==============================================================
   9.137  =
   9.138 +=   Use cases
   9.139  =
   9.140 -==============================================
   9.141 -So, question..  what do display list elements look like?  Does visualizer produce the layout, for example, specify a bounding box and position for each element, including text, lines, etc?  Does it produce the bezier curves in SVG that connect syntax graph elements?
   9.142 +==============================================================
   9.143  
   9.144 -Or, does it send something with fewer details?  Let the Display calculate exact placement of visual elements?
   9.145 +-] hit space bar, which brings up the menu that shows the key mappings.. 
   9.146  
   9.147 -What about pan and zoom?  Does Visualizer handle that, or Display..  pan means moving some elements out of the painted canvas and moving others in..  zoom does too, in addition to calculating new transforms for each element painted..  So, if Display does this, then it must either have all the visual elements in it, or else it much send a request to Visualizer that triggers sending what's needed..
   9.148 +-] make code that draws the "menu" rectangle
   9.149 +- -] give it a z that is in front of the other surfaces, perhaps 80% opaque
   9.150  
   9.151 -Soooo..  make a two-way path between Display and Visualizer, in order to handle pan, zoom, 3D rotates, and so forth?
   9.152 +-] hit 'e' key near an elem box, have an arrow spring out, from "portsOut" to the cursor.
   9.153  
   9.154 -Orrrr..  leave that to the MVDM loop..  the pan/zoom/rotate gestures go into the command-maker, and thence into the visualizer, which then sends view update..
   9.155 +-] move cursor, have the arrow track the cursor
   9.156  
   9.157 -sooo..  this view update stuff..  does Display keep a full representation of the visual elements, and then translate that into Famo.us elements?  Or, does it keep, say, a current visualizer list..  where visualizer updates simply modify the previous list sent..  then Display translates the updated list into Famo.us elements..  given that Famo.us doesn't support removing render tree elements, that might be a good approach..  and it simplifies the thing about how to figure out what a visualizer update is and what to do with it inside the Display.
   9.158 +-] hit 'e' key again near a different elem box, have the arrow terminate at "portsIn" of that elem box
   9.159  
   9.160 -Okay.. now..  just need to figure out what the Visualizer actually sends..  how much detail..
   9.161 +-] over empty background, hit 'a' key, have that pop up a new elem box
   9.162  
   9.163 -You know what?  I don't want to think about it!  Just going to do something, see what happens, and then can modify later..  probably will never get modified, these choices have a way of sticking, due to momentum of volume of work and low improvement in changing..  but, don't want to stall myself, need to keep moving..
   9.164 +-] near that elem box, hit 's', have that create a new properties box and connect an arrow from the elem box's "properties" over to the new properties box.  (If can't find a nearby elem or other properties box, then just make an orphan properties box?)
   9.165  
   9.166 -sooooo...  something has to calculate placement of bounding boxes, and calculate translations and sizing..  and move things in and out based on zoom, pan, rotate..  and trigger redraws and resends of display data for graphs and calculation results..  seems like if put placement and transform calcs inside Display then are making the Display an active thing, giving it intelligence and control..  then, run into problems when have a view that is composed of pieces from many different holders and different processors..  for example, displaying a worksheet, where the worksheet itself is in a holder that generates a view, and locations on the worksheet are calculated by live processors, and locations are graphs which are generated by graphing processors that take calculations from other processors..  want the worksheet holder to handle generating the view, and collecting the data from the other processors..  don't want the Display to have any kind of intelligence related to this!  
   9.167 +-] hit 'f' key, have it zoom in on the box under the cursor
   9.168  
   9.169 -Hmmm..  so, if the worksheet holder is doing all of the collecting of data and triggering re-calcs, and melding together into a view..  then Display is simply passively painting that and collecting gestures that it sends back..  the holder then knows what to do with the gestures performed upon view elements..  
   9.170 +-] inside the box, hit arrow keys to move cursor between fields
   9.171 +- -] at each field, use space to pop up another menu and then space again to un-pop it..  
   9.172 +- -] make this menu relate to the valid entries for the field.  For one field, show valid sequences that uniquely identify one of the valid values for the field (ex, for the "element type" field).
   9.173 +- -] make menu be hierarchical -- first menu chooses a field via a key -- second menu shows all unique sequences for values in the field
   9.174 +- -] have the menu for the "variable Name" field simply say "type in alpha-numeric text, which can include spaces but no other whitespace)
   9.175  
   9.176 -So that means that the Display should not be calculating pan and zoom and rotate!!  Those are responses to gestures, and those trigger behaviors from the visualizer (which may, in turn, have to trigger behaviors from other processors in order to get updated calcs to put into the view)
   9.177 -
   9.178 -Got it, so as tempting as it is to peel off such gestures in the Display and build intelligence into there..  it will cause problems..  so best to have all the visual related processing be done inside the visualizers..  
   9.179 -
   9.180 -so..  means the visualizer should send out things pretty close to renderable..
   9.181 -
   9.182 -Now.  The question comes up..  what format?  Does the visualizer send out SVG?  Is that universal enough?  Will that cause problems with non-browser based approaches?  If not SVG, then what?  Will need to represent paths..  does visualizer calculate Bezier curves and send those?  Or does it just say "here are end points, connect these with a smooth path"?  Does the visualizer calculate how to route arcs within a graph around the other nodes in an optimal way?  If the user supplies helpers by moving things, does the Display remember that, or the Visualizer?  
   9.183 -
   9.184 -Ahhhh..  okay..  if what the user to be able to affect the visual arrangement, then need to remember the gestures they give that are related to visual arrangement..  for example, they grab bezier control points and move them, in order to affect a curve, or add new points within a path in order to route it..  those things have to be remembered!  The Display has no place to store such things!!
   9.185 -
   9.186 -Right..  that means that the holder must store info related to viewing the holder contents!  sooooo..  the visualizer must be the thing that generates any details that a person may want to adjust.
   9.187 -
   9.188 -Right.  Any visual arrangement that a person might want to adjust must be stored inside the holder, and so the visualizer must be the thing that generates that level of detail.  Right.  Got it.
   9.189 -
   9.190 -So.  Yes.  That means that the visualizer must send out bounding boxes, translations, sizing, path points, control points, and so forth.  So.  Yes.  SVG is looking like a good way to go..  has to be something!  Can invent my own equivalent, which specifies paths, shapes, widths, and so forth..  but what is the gain?  The only potential is sending in binary, to save the overhead of SVG's text embodiment.  The savings worth the effort?  NO!
   9.191 -
   9.192 -Okay then.  SVG.  That is the visualizer's format for POP.  Or perhaps it just sends the values that go into the SVG?  The Display does the final conversion to text-based SVG format?  Hmmmm, what about custom syntax, which is SVG from the programmer?  Just send indication of SVG elements, together with the values?  Maybe enums for the SVG indicators, or something..
   9.193 -
   9.194 -Now.  Question is, how much effort?  Is it more effort to send a representation, then construct text-repr inside Display?  Or more effort to construct SVG text in visualizer and send it ready-made?
   9.195 -
   9.196 -Seems easier to just construct SVG text inside visualizer and send that.. 
   9.197 -
   9.198 -Heck, if send representation, then are already forcing SVG!  It doesn't constrain the Display if send the text form..  the display is just as free to convert the binary form to something else as it is to convert the text form to something else..  so if Display is not browser, and doesn't have SVG drawing primitives, it has to do the extra step of parsing SVG in order to extract the values from the text, and then generate whatever internal form it has, such as calculating paths or even pixels itself..  the extraction from text does not seem like a terribly large burden compared to the rest.
   9.199 -
   9.200 -Buuuut..  don't really care!  Going to generate text form inside visualizer, because, why not?  Then the Display only translates displayList elements into its internal thing that paints.  In the case of browser, Display translates display list into famo.us elements, placing the SVG verbatim onto famous surfaces, and makes the SVG bounding box the same as the famous surface size.
   9.201 -
   9.202 -In fact, display list is going to represent almost verbatim what a Famo.us render tree will look like!  It is a fairly universal declaration..  hierarchy of local visual contexts, with relationship among those contexts, including relative placement in 3D space and relative sizing from one to another.
   9.203 -
   9.204 -Alright, getting to it now..  display list will be a serialization of a hierarchy..  The top of the hierarchy is the view painted onto.  The Display tells the visualizer what the pixel dimensions are of the view.  The visualizer makes that the top level bounding box.  It then inserts bounding boxes within that, and inserts bounding boxes within those, and so forth down.  Each bounding box is either a hierarchy element, relationship element, or a painted element.  Hierarchy elements simply state what elements are included, and give their own bounding box.  Relationship elements are attached by the parent hierarchy element.  For example, it is the job of the parent to make sure all the children fit inside its bounding box.  The bounding box may be 2D or 3D.  A parent ensures the fit by attaching relationships to the children elements.  The relationships can be translations or scalings or rotations.. or actually any arbitrary 3D transform.  A hierarchy element knows nothing of the context in which it fits, so it has no way of attaching relationships to itself!  Each hierarchy element is responsible for ensuring that all descendants fit within its bounding box.  Any relationship attached to a hierarchy element is transitively applied to all descendants of the hierarchy element.  For example, if one is rotated in 3D, then it, together with all its contents, is rotated as a unit.  Each descendant maintains the same relationship to its parent as before..  but the entire bundle has been rotated as a unit!
   9.205 -
   9.206 -Great..  so that is the display list..  it is a serialization of that hierarchy.  A display update then assumes a given hierarchy, and says "change this relationship between this parent and this child" or "remove this parent and all descendants" etc..  in effect, it specifies a change to the hierarchical structure..
   9.207 -
   9.208 -Sooooo..  means that have two copies of the view hierarchy..  one inside the visualizer, which is serialized, and another inside the Display, which is translated into Display-local elements that are then painted.
   9.209 -
   9.210 -Not the most efficient..  hurts me..  but, well, what are you going to do?  What's better?  Need the flexibility of having the visualizer control all changes to the view hierarchy.. and need the visualizer to calculate all placement and path details so that user changes can be remembered inside the holder (without something clunky like "save this view modification info as a black box and hand it to the Display, which knows what it means" yuck, just begging for loss of sync when move from one Display to another or even upgrade the Display!)..  
   9.211 -
   9.212 -so, then, there's no way around having the visualizer internally represent the bounding box hierarchy as it constructs the details.  Thennnnn..  something must translate that representation into the internal Display representation!  The Display could have any native form internally..  canvas with paths drawn upon it, Java 2D, even just pixels, with all the code in between..  well, in effect, every Display ends up being everything between that hierarchy and on down to pixels!!
   9.213 -
   9.214 -So, could just hand the data structure from visualizer to the Display..?  This is fine if both are inside same hardware, sharing memory..  but need a serialization if Display has separate memory..  which it will if the src holder is on a server and the display is a browser on a client!
   9.215 -
   9.216 -Hmmm..  what about just handing the data structure to the Display for now..  can always add the serialization later, it's not functional!  :-)  Ahhh, yes.. less work.  Good.  Okay, will do that.  save serialization for later.  For now, in javascript, will build a src holder that saves syntax graph natively in JSON, as an internal data structure of the form made for GabePatterns.  The visualizer in the src holder will generate a view hierarchy from that data structure.  It will save any view related data within the syntax graph data structure as extra properties added to the nodes.  The visualizer will then hand a reference to the view hierarchy directly to the display object.  The display object will then generate famous elements from the view hierarcy elements.  View updates will simply be the visualizer changing the view hierarchy then calling the display with a reference to the changed hierarchy.
   9.217 -
   9.218 -Done.  Make it so.
   9.219 -
   9.220 -BTW, thinking to introduce another component, which is a helper, that maybe takes some higher level view form and generates the view hierarchy from that..  this will ease the burden on developers who make custom syntax.. it will act as a library for them, essentially..  (and, of course, there will be a serializer that turns a view hierarchy into a stream of visual objects sent to the Display, which will reconstruct the view hierarchy then translate that into into elements that it paints.. for now, that serializer is just JSON!  It has provision to translate javascript objects into text form, and then on the other side parse that text form to reproduce the javascript objects.. might need extra logic in order to recreate the links among parents and children.. not sure whether JSON can go deep that way..).
   9.221 -
   9.222 +========================================================
   9.223  
   9.224   
   9.225  
   9.226  
   9.227 + 
   9.228 + 
   9.229  
   9.230 +
   9.231 +

    10.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    10.2 +++ b/2__Ideas/14_Jy_07__code_reuse__inheritance_inline_etc.txt	Wed Jul 23 18:51:15 2014 -0700
    10.3 @@ -0,0 +1,19 @@
    10.4 +Actually, there are multiple kinds of code re-use:
    10.5 +-] in-line code, where have something that assumes a context (such as variables in the scope), and grabs what matches within that context and inserts that into the respective places inside its body.  For example, a macro does this, so do in-line functions.
    10.6 +-] processors that are communicated with.  Many function calls are this -- other places in the code are other processors, that send parameters to the function, and receive back a return response.
    10.7 +-] inheritance, where have a namespace hierarchy that is searched.. the context can be assigned to a variable, then a function name can be looked up within it (assigning an object to a variable equals assigning a namespace to a variable).  If the function name isn't found in the immediate context, then the parent(s) of that context is(are) searched, until the name is found.  So, code is re-used by making it accessible from a parent name-space.
    10.8 +
    10.9 +In POP, in-line code has four forms:
   10.10 +-] meta-agents inside the syntax-graph/MVDM-loop, which contain code that is used as part of generating code that is inserted into the syntax graph.  For example, active syntax generates code at the point that the user gives the gesture to add it to the syntax graph.
   10.11 +-] selecting a hierarchy unit to be deep-copied to the current hole in the syntax graph (the syntax-graph of the original is duplicated)
   10.12 +-] selecting a hierarchy unit to be reference-inserted into the hole (the syntax graph of the original is hooked to, not duplicated)
   10.13 +-] macros -- in POP these are both meta-agents and also deep copies.  The macro selects things from the code surrounding where it is placed, and sucks those inside itself, and puts in a copy thus modified, into the syntax graph.
   10.14 +
   10.15 +In POP, processor-communicated-with code has at least two forms:
   10.16 +-] connecting the inputs and outputs of one code-processor to another (this can be implied, for example on a worksheet, or direct, using the MVDM loop while in System (OS) view)
   10.17 +-] when sending a context to a processor-box, it creates a new processor to handle the incoming context.  That is equivalent to copies of the code at runtime, talking to each other -- the creation as well as the contents is communication..  but it's not like other forms, where inputs are connected to outputs!
   10.18 +
   10.19 +In POP, inheritance can be accomplished via the copy-by-reference mechanism, or via the send-a-namespace/context mechanism (simply insert the variable connected to the processor that you want to receive sent data.. same variable name in each context, connected to different processors == polymorphism..  and the parent context attached, that has functions attached to names in it == inheritance)
   10.20 +
   10.21 +In effect, POP has functional, object oriented, procedural, and declarative styles that can be done within it.  At least, the underlying mechanisms that set those things apart are all available within POP.
   10.22 +

    11.1 Binary file 2__Ideas/POP__Ideas - Shortcut.lnk has changed