[Gzz-commits] fenfire/docs/pegboard/nodeview_abstract--mudyc ...

[Matti Katila]

CVSROOT:        /cvsroot/fenfire
Module name:    fenfire
Changes by:     Matti Katila <address@hidden>   03/04/04 02:14:53

Modified files:
        docs/pegboard/nodeview_abstract--mudyc: peg.rst 

Log message:
        hop hop..

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst.diff?tr1=1.4&tr2=1.5&r1=text&r2=text

Patches:
Index: fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst
diff -u fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.4 
fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.5
--- fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.4  Wed Apr  2 
12:46:09 2003
+++ fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst      Fri Apr  4 
02:14:52 2003
@@ -4,10 +4,32 @@
 
 :Author:   Matti Katila
 :Stakeholders: Matti Katila
-:Last-Modified: $Date: 2003/04/02 17:46:09 $
-:Revision: $Revision: 1.4 $
+:Last-Modified: $Date: 2003/04/04 07:14:52 $
+:Revision: $Revision: 1.5 $
 :Status: Incomplete  
 
+
+Introduction
+""""""""""""
+
+This PEG includes three abstract which are
+
+    - Node content ('NodeView')
+    - Node content state ('xyzState')
+    - Node content with view context ('xyzContext')
+ 
+       - xyz implicates Text, Image, Sound and Page etc.
+
+Another PEG will explain the enfilade handling of nodes.
+This PEG only tells how node is to be placed knowning
+nothing about the content.
+
+
+
+1) Simple way to place a node without a fear of wrong span
+==========================================================
+
+
 Abstract
 --------
 
@@ -20,200 +42,155 @@
 easily be able to show any content in nodes.
 
 
-Paragraph
----------
-
-The Idea
-""""""""
-
-We need abstract layer where we can just place a node and 
-where we shouldn't need to know what kind of types of spans 
-are in the node's enfilade.
-
+Issues
+------
 
-NodeView
-""""""""
-- org.fenfire.nodeview
+   - Should getsize return float[2] or Dimension?
 
-The idea is to give a node to NodeView and let it put 
-the right media type in the vobscene without of the fear of wrong span.
-Giving the node is done through the NodeContent interface (place method)
-which is implemented by NodeView.
 
+Changes
+-------
 
-ContentHandler
-""""""""""""""
-- org.fenfire.nodeview.handler
+We need an abstract layer where we can just place a node and 
+where we shouldn't need to know what kind of types of spans 
+are in the node's enfilade. 
 
-For different media types there must be handlers which can 
-present the given enfilade right way.
+::
 
-Let's start with:
-   
-   - TextHandler
-   - ImageHandler
-   - PageSpanHandler
+   CellView was abstract class:
    
-which implement ContentHandler. One important thing is that 
-handlers do not work with nodes but enfilades. 
-
+      public abstract void place(Cell c, VobScene vs, int box,
+                                 ViewContext context);
+      public void getSize(Cell c, float scale, ViewContext context,
+                          float[] out) {
+         getSize(c, context, out);
+      }
+   }
 
-NodeView.Attrib
-"""""""""""""""
-- org.fenfire.nodeview
+I propous that we abstract ViewContext away and let 
+someone else to handle the view context. 
 
-So, if texthandler wants to know the cursoroffset to render cursor, 
-texthandler must ask it from NodeView.text or if PageSpanHandler 
-wants to know the position for page spans pagespanhandler must ask it from 
NodeView.pagespan
+::
 
-NodeView.text and NodeView.pagespan are extended of the NodeView's subclass 
NodeView.Attrib.
+     public interface NodeContent {
+         void place(RDFNode node, VobScene vs, int box);
+         void getSize(RDFNode node, float[] size, float scale=1);
+     }
 
-TextAttrib which extends NodeView.Attrib would have methods get/set 
cursorOffset. 
-Otoh, PageSpanAttrib would have methods best for it.
+We want to be able just to say nodeview.place(...); and know nothing 
+about view context nor node's content.
 
-Suitable NodeView.Attrib will be passed to correct ContentHandler among other 
attributes.
+Note:
+   - **Very important thing** is that we don't know anything
+     about the content. We can only assume what an enfilade includes. 
+     That's why I like to propouse additional methods to NodeContent 
+     interface which would be:
 
+::
 
-NodeViewContext
-"""""""""""""""
-- org.fenfire.nodeview
+    public interface NodeContent {
+         void place(RDFNode node, VobScene vs, int box);
+         void getSize(RDFNode node, float[] size, float scale=1);
 
-There's continuous need to identify the accursed node. 
-For example text could be reddish if it is focused or 
-different box can be drawn in Loom like view if node is accursed.
+         // has methods - ask from enfilade if it contains specified span.
+         boolean hasText(RDFNode node);
+         boolean hasImage(RDFNode node);
+         boolean hasPageSpan(RDFNode node);
+    }
 
-That's why NodeView implements NodeViewContext which has only ''get/set 
accursed node'' interface.
+NodeContent interface should be implemented by *NodeView*.
 
 
-Multicontent and Future
-"""""""""""""""""""""""
 
-By splitting nodeview to handlers we also ensure the future about multicontent 
nodeviews.
-Multicontent node view can now be easily extended from NodeView, make it split 
enfilades to
-adequate handler and there it is.
+2) Simple way to change the state of the node content view
+==========================================================
 
 
-getSize
--------
+Abstract
+--------
 
-You can ask from NodeContent to get width and height of the content in 1:1 
factor.
-This makes it easier to make zoomable views. NodeView implements NodeContent.
+It hasn't been very easy to say: "Write this text with red color" or 
+"draw pagespan without the background texture". As I previously said about 
+node content we don't even know if we have text and/or pagespan but **if we 
have**
+we want to change it's state to this or that.
 
 
 Issues
 ------
 
-   - How this PEG affect to view_split--tjl ?
+None
 
-      RESOLVED:
 
-         -PEG's status is irrelevant.
+Changes
+-------
 
-   - How this PEG affect to cellview_naming--benja?
+I propous several interfaces to be implemented by suitable content state 
handler: 
 
-      RESOLVED:
+::
 
-         -PEG's status is irrelevant.
+   public interface TextState {
+      // color
+      void setColor(Color c);
+      Color getColor();
 
-   - What's view? I think view is buzzword. It says too much and nothing. 
-     In Loom there are simple and wheel view but the change between them is 
-     just about geometry. The reason I'm raising this issue now is about 
-     package naming and future where I think it's more common to view 
-     heap of nodes(you can image them as links also) instead of just one node. 
+      // font
+      void setFont(Style style);
+      Style getFont();
+   }
 
-   - What if one wants to change color of text?
+   public interface PageState {
+      void setBackgroundTexVisible(boolean b);
+   }      
 
-      RESOLVED:
-  
-         - NodeView.text.setColor(Color c) which replaces or sets
-           current TextVob with better color.
 
-   - Do we really need ContentHandler interface?
+These would be easily called from NodeView public attributes, i.e.,
+nodeview.text.setColor(Color.red); or 
nodeview.pagespan.setBackgroundTexVisible(false);
 
-      I don't know if java has speed problems because of this as does C++ has. 
-      If it has got speed issue we can forget handler interface and call 
directly
-      the specific handler.
 
-   - How this PEG affect to ViewContext?
 
-      RESOLVED:
-         
-         In Loom like view extend NodeView to LoomView by implementing the 
-         old ViewContext. This change makes it very easy to transfer all 
-         wanted data around without java's ugly type casting.
+3) Definied way to handle view context when placing a node
+==========================================================
 
-   - Is NodeViewContext in right place? Should this be an issue as same as the 
-     previous ViewContext issue?
 
-      UNRESOLVED.
+Abstract
+--------
 
-   - Should getSize return Dimension rather than float[2]?
+View context isn't very easy task. When you place a node it's correct time to 
ask from
+view context if it has plans for current node. View context might want to set 
+cursor offset, pagespan view coordinates or it might want to set text's 
+color more important by reddishing for example.
 
-      UNRESOLVED.
 
+Issues
+------
 
-UML figure
-----------
+None
 
-.. UML:: Abstract-of-NodeView
 
-   class NodeViewContext "interface"
-      methods
-         RDFNode getAccursed()
-         void setAccursed(RDFNode node)
- 
-   class NodeContent "interface"
-      methods
-         +float[] getSize(RDFNode node, float scale=1)
-         +void place(RDFNode node, VobScene vs, int box)
-
-   class NodeView "Abstract"
-      realize NodeViewContext
-      realize NodeContent 
-      fields
-         +ContentHandler textHandler
-         +ContentHandler imageHandler
-         +ContentHandler pageSpanHandler
-         -RDFNode accursed
-         +TextAttrib text
-         +ImageAttrib image
-         +PageSpanAttrib pagespan
-
-   class NodeView.Attrib "SubClassOfNodeView"
-
-   class ContentHandler "interface"
-      methods
-         +void place(VobScene vs, int box, Enfilade enf, NodeView.Attrib 
attrib, boolean accursed=false)
-         +float[] getSize(Enfilade enf)
-
-   class TextHandler
-      realize ContentHandler
-
-   class TextAttrib
-      inherit NodeView.Attrib
-      methods
-         int getCursorOffset(RDFNode node=null)
-         void setCursorOffset(int offs, RFDNode node)
+Changes
+-------
 
-   class ImageHandler
-      realize ContentHandler
-   
-   class PageSpanHandler
-      realize ContentHandler
+When NodeView has a new node to place it should mention it to ViewContext.
+
+So ViewContext should implement the following interface:
+
+::
+
+   public interface NodeViewContext {
+      nodeIsToBePlaced(RDFNode current, NodeView nv);
+   }
 
-   class PageSpanAttrib
-      inherit NodeView.Attrib
-      methods
-         int getFooo
+And now ViewContext is able to do it's job if we define new interfaces:
 
+::
 
-   dep "gets cursorOffset or pagespan attributes etc.." ContentHandler NodeView
-   dep "subClass" NodeView.Attrib NodeView              
+    public interface TextContext {
+        void setCursorOffset(int off);
+        int getCursorOffset();
+    }
 
-   -----
-   horizontally(150, cont_h, TextHandler, ImageHandler, PageSpanHandler);
-   horizontally(150, node_h, NodeViewContext, NodeContent);
-   vertically(200, all, ImageHandler, ContentHandler, NodeView, 
NodeViewContext); 
+    public interface PageContext {
+        void setViewCoords(float x, float y);
+        float[] getViewCoords();
+    }
 
-   horizontally(150, nodeview_h, NodeView, NodeView.Attrib, TextAttrib);
-   vertically(50, attrib, TextAttrib, PageSpanAttrib)
\ No newline at end of file