/[fenfire]/fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst
ViewVC logotype

Diff of /fenfire/docs/pegboard/nodeview_abstract--mudyc/peg.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.4 by mudyc, Wed Apr 2 17:46:09 2003 UTC revision 1.5 by mudyc, Fri Apr 4 07:14:52 2003 UTC
# Line 8  PEG nodeview_abstract--mudyc: Abstract n Line 8  PEG nodeview_abstract--mudyc: Abstract n
8  :Revision: $Revision$  :Revision: $Revision$
9  :Status: Incomplete    :Status: Incomplete  
10    
11    
12    Introduction
13    """"""""""""
14    
15    This PEG includes three abstract which are
16    
17        - Node content ('NodeView')
18        - Node content state ('xyzState')
19        - Node content with view context ('xyzContext')
20    
21           - xyz implicates Text, Image, Sound and Page etc.
22    
23    Another PEG will explain the enfilade handling of nodes.
24    This PEG only tells how node is to be placed knowning
25    nothing about the content.
26    
27    
28    
29    1) Simple way to place a node without a fear of wrong span
30    ==========================================================
31    
32    
33  Abstract  Abstract
34  --------  --------
35    
# Line 20  Although text is the most common view me Line 42  Although text is the most common view me
42  easily be able to show any content in nodes.  easily be able to show any content in nodes.
43    
44    
45  Paragraph  Issues
46  ---------  ------
   
 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.  
   
47    
48  NodeView     - Should getsize return float[2] or Dimension?
 """"""""  
 - org.fenfire.nodeview  
49    
 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.  
50    
51    Changes
52    -------
53    
54  ContentHandler  We need an abstract layer where we can just place a node and
55  """"""""""""""  where we shouldn't need to know what kind of types of spans
56  - org.fenfire.nodeview.handler  are in the node's enfilade.
57    
58  For different media types there must be handlers which can  ::
 present the given enfilade right way.  
59    
60  Let's start with:     CellView was abstract class:
     
    - TextHandler  
    - ImageHandler  
    - PageSpanHandler  
61        
62  which implement ContentHandler. One important thing is that        public abstract void place(Cell c, VobScene vs, int box,
63  handlers do not work with nodes but enfilades.                                   ViewContext context);
64          public void getSize(Cell c, float scale, ViewContext context,
65                              float[] out) {
66              getSize(c, context, out);
67          }
68       }
69    
70  NodeView.Attrib  I propous that we abstract ViewContext away and let
71  """""""""""""""  someone else to handle the view context.
 - org.fenfire.nodeview  
72    
73  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  
74    
75  NodeView.text and NodeView.pagespan are extended of the NodeView's subclass NodeView.Attrib.       public interface NodeContent {
76             void place(RDFNode node, VobScene vs, int box);
77             void getSize(RDFNode node, float[] size, float scale=1);
78         }
79    
80  TextAttrib which extends NodeView.Attrib would have methods get/set cursorOffset.  We want to be able just to say nodeview.place(...); and know nothing
81  Otoh, PageSpanAttrib would have methods best for it.  about view context nor node's content.
82    
83  Suitable NodeView.Attrib will be passed to correct ContentHandler among other attributes.  Note:
84       - **Very important thing** is that we don't know anything
85         about the content. We can only assume what an enfilade includes.
86         That's why I like to propouse additional methods to NodeContent
87         interface which would be:
88    
89    ::
90    
91  NodeViewContext      public interface NodeContent {
92  """""""""""""""           void place(RDFNode node, VobScene vs, int box);
93  - org.fenfire.nodeview           void getSize(RDFNode node, float[] size, float scale=1);
94    
95  There's continuous need to identify the accursed node.           // has methods - ask from enfilade if it contains specified span.
96  For example text could be reddish if it is focused or           boolean hasText(RDFNode node);
97  different box can be drawn in Loom like view if node is accursed.           boolean hasImage(RDFNode node);
98             boolean hasPageSpan(RDFNode node);
99        }
100    
101  That's why NodeView implements NodeViewContext which has only ''get/set accursed node'' interface.  NodeContent interface should be implemented by *NodeView*.
102    
103    
 Multicontent and Future  
 """""""""""""""""""""""  
104    
105  By splitting nodeview to handlers we also ensure the future about multicontent nodeviews.  2) Simple way to change the state of the node content view
106  Multicontent node view can now be easily extended from NodeView, make it split enfilades to  ==========================================================
 adequate handler and there it is.  
107    
108    
109  getSize  Abstract
110  -------  --------
111    
112  You can ask from NodeContent to get width and height of the content in 1:1 factor.  It hasn't been very easy to say: "Write this text with red color" or
113  This makes it easier to make zoomable views. NodeView implements NodeContent.  "draw pagespan without the background texture". As I previously said about
114    node content we don't even know if we have text and/or pagespan but **if we have**
115    we want to change it's state to this or that.
116    
117    
118  Issues  Issues
119  ------  ------
120    
121     - How this PEG affect to view_split--tjl ?  None
122    
       RESOLVED:  
123    
124           -PEG's status is irrelevant.  Changes
125    -------
126    
127     - How this PEG affect to cellview_naming--benja?  I propous several interfaces to be implemented by suitable content state handler:
128    
129        RESOLVED:  ::
130    
131           -PEG's status is irrelevant.     public interface TextState {
132          // color
133          void setColor(Color c);
134          Color getColor();
135    
136     - What's view? I think view is buzzword. It says too much and nothing.        // font
137       In Loom there are simple and wheel view but the change between them is        void setFont(Style style);
138       just about geometry. The reason I'm raising this issue now is about        Style getFont();
139       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.  
140    
141     - What if one wants to change color of text?     public interface PageState {
142          void setBackgroundTexVisible(boolean b);
143       }      
144    
       RESOLVED:  
     
          - NodeView.text.setColor(Color c) which replaces or sets  
            current TextVob with better color.  
145    
146     - Do we really need ContentHandler interface?  These would be easily called from NodeView public attributes, i.e.,
147    nodeview.text.setColor(Color.red); or nodeview.pagespan.setBackgroundTexVisible(false);
148    
       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.  
149    
    - How this PEG affect to ViewContext?  
150    
151        RESOLVED:  3) Definied way to handle view context when placing a node
152            ==========================================================
          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.  
153    
    - Is NodeViewContext in right place? Should this be an issue as same as the  
      previous ViewContext issue?  
154    
155        UNRESOLVED.  Abstract
156    --------
157    
158     - 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
159    view context if it has plans for current node. View context might want to set
160    cursor offset, pagespan view coordinates or it might want to set text's
161    color more important by reddishing for example.
162    
       UNRESOLVED.  
163    
164    Issues
165    ------
166    
167  UML figure  None
 ----------  
168    
 .. UML:: Abstract-of-NodeView  
169    
170     class NodeViewContext "interface"  Changes
171        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)  
172    
173     class ImageHandler  When NodeView has a new node to place it should mention it to ViewContext.
174        realize ContentHandler  
175      So ViewContext should implement the following interface:
176     class PageSpanHandler  
177        realize ContentHandler  ::
178    
179       public interface NodeViewContext {
180          nodeIsToBePlaced(RDFNode current, NodeView nv);
181       }
182    
183     class PageSpanAttrib  And now ViewContext is able to do it's job if we define new interfaces:
       inherit NodeView.Attrib  
       methods  
          int getFooo  
184    
185    ::
186    
187     dep "gets cursorOffset or pagespan attributes etc.." ContentHandler NodeView      public interface TextContext {
188     dep "subClass" NodeView.Attrib NodeView                        void setCursorOffset(int off);
189            int getCursorOffset();
190        }
191    
192     -----      public interface PageContext {
193     horizontally(150, cont_h, TextHandler, ImageHandler, PageSpanHandler);          void setViewCoords(float x, float y);
194     horizontally(150, node_h, NodeViewContext, NodeContent);          float[] getViewCoords();
195     vertically(200, all, ImageHandler, ContentHandler, NodeView, NodeViewContext);      }
196    
    horizontally(150, nodeview_h, NodeView, NodeView.Attrib, TextAttrib);  
    vertically(50, attrib, TextAttrib, PageSpanAttrib)  

Legend:
Removed from v.1.4  
changed lines
  Added in v.1.5

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26