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

[Matti Katila]

CVSROOT:        /cvsroot/fenfire
Module name:    fenfire
Changes by:     Matti Katila <address@hidden>   03/04/02 12:27:08

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

Log message:
        Ok, it finally seems to be in some order. I definitely need to practise
        writing...

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/fenfire/fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst.diff?tr1=1.2&tr2=1.3&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.2 
fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.3
--- fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst:1.2  Wed Apr  2 
06:41:29 2003
+++ fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst      Wed Apr  2 
12:27:07 2003
@@ -4,8 +4,8 @@
 
 :Author:   Matti Katila
 :Stakeholders: Matti Katila
-:Last-Modified: $Date: 2003/04/02 11:41:29 $
-:Revision: $Revision: 1.2 $
+:Last-Modified: $Date: 2003/04/02 17:27:07 $
+:Revision: $Revision: 1.3 $
 :Status: Incomplete  
 
 Abstract
@@ -52,7 +52,7 @@
    - ImageHandler
    - PageSpanHandler
    
-which implements ContentHandler. One important thing is that 
+which implement ContentHandler. One important thing is that 
 handlers do not work with nodes but enfilades. 
 
 
@@ -66,10 +66,10 @@
 
 NodeView.text and NodeView.pagespan are extended of the NodeView's subclass 
NodeView.Attrib.
 
-TextAttr which extends NodeView.Attributes would have methods get/set 
cursorOffset. 
-Otoh, PageSpanAttr would have methods best for it.
+TextAttrib which extends NodeView.Attrib would have methods get/set 
cursorOffset. 
+Otoh, PageSpanAttrib would have methods best for it.
 
-Suitable NodeView.Attrib will be passed to ContentHandler among other 
attributes.
+Suitable NodeView.Attrib will be passed to correct ContentHandler among other 
attributes.
 
 
 NodeViewContext
@@ -88,12 +88,14 @@
 
 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!
+adequate handler and there it is.
 
-get"Size"
----------
 
-You can ask from NodeContent to get width and height.
+getSize
+-------
+
+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.
 
 
 Issues
@@ -101,20 +103,51 @@
 
    - How this PEG affect to view_split--tjl ?
 
+      RESOLVED:
+
+         -PEG's status is irrelevant.
+
    - How this PEG affect to cellview_naming--benja?
 
+      RESOLVED:
+
+         -PEG's status is irrelevant.
+
    - 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. 
 
+   - What if one wants to change color of text?
+
+      RESOLVED:
+  
+         - NodeView.text.setColor(Color c) which replaces or sets
+           current TextVob with better color.
+
+   - Do we really need ContentHandler interface?
+
+      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.
+
+   - Is NodeViewContext in right place? Should this be an issue as same as the 
+     previous ViewContext issue?
+
+      UNRESOLVED.
 
-Optional Changes
-----------------
+   - Should getSize return Dimension rather than float[2]?
 
-In Loom like view extend NodeView to LoomView implementing the old ViewContext.
-This change makes it very easy to transfer all wanted data around without 
java's ugly type casting.
+      UNRESOLVED.
 
 
 UML figure
@@ -125,11 +158,11 @@
    class NodeViewContext "interface"
       methods
          RDFNode getAccursed()
-         void setRDFNode(RDFNode node)
+         void setAccursed(RDFNode node)
  
    class NodeContent "interface"
       methods
-         +float[] getW[idth]H[eight](RDFNode node, float scale=1)
+         +float[] getSize(RDFNode node, float scale=1)
          +void place(RDFNode node, VobScene vs, int box)
 
    class NodeView "Abstract"
@@ -140,16 +173,16 @@
          +ContentHandler imageHandler
          +ContentHandler pageSpanHandler
          -RDFNode accursed
-         +NodeView.Attrib text
-         +NodeView.Attrib image
-         +NodeView.Attrib pagespan
+         +TextAttrib text
+         +ImageAttrib image
+         +PageSpanAttrib pagespan
 
-   class NodeView.Attrib SubClassOfNodeView
+   class NodeView.Attrib "SubClassOfNodeView"
 
    class ContentHandler "interface"
       methods
-         +void place(VobScene vs, int box, Enfilade enf, NodeView.Attrib 
attrib, RDFNode accursed=null)
-         +float[] getW[idth]H[eight](Enfilade enf)
+         +void place(VobScene vs, int box, Enfilade enf, NodeView.Attrib 
attrib, boolean accursed=false)
+         +float[] getSize(Enfilade enf)
 
    class TextHandler
       realize ContentHandler
@@ -180,5 +213,5 @@
    horizontally(150, node_h, NodeViewContext, NodeContent);
    vertically(200, all, ImageHandler, ContentHandler, NodeView, 
NodeViewContext); 
 
-   horizontally(100, nodeview_h, NodeView, NodeView.Attrib, TextAttrib);
+   horizontally(150, nodeview_h, NodeView, NodeView.Attrib, TextAttrib);
    vertically(50, attrib, TextAttrib, PageSpanAttrib)