/[gzz]/gzz/doc/pegboard/1018/PEG_1018.rst
ViewVC logotype

Diff of /gzz/doc/pegboard/1018/PEG_1018.rst

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

revision 1.3 by benja, Thu Nov 14 15:40:07 2002 UTC revision 1.4 by humppake, Tue Dec 10 16:06:39 2002 UTC
# Line 1  Line 1 
1  =============================================================  ==========================================================================
2  PEG 1018: Generalizing VobVanishingClient  PEG 1018: ViewTool (was generalizing VobVanishingClient)
3  =============================================================  ==========================================================================
4    
5  :Author:   Asko Soukka  :Author:   Asko Soukka, Benja Fallenstein
6    :Date-created: 2002-12-10
7  :Last-Modified: $Date$  :Last-Modified: $Date$
8  :Revision: $Revision$  :Revision: $Revision$
9  :Status:   Incomplete  :Status:   Incomplete
10    
11  Yes, I believe that the view interface in 0.8 is much more  This PEG is about creating a ViewTool. The ViewTool would offer easy-to-use
12  flexible than the on in 0.6. Although I had been working  interface for prototyping new views - and lowering the treshold of starting
13  on 0.8 for weeks, I still had problems to get used to those  view development.
14  coordsys transformations everywhere. I think there should be  
15  easy-to-use interface for prototyping new views. Something with  PS. UML-diagrams are not currently compiled with this PEG, but
16  you can start directly putting some vobs into space and see  by "make uml", sorry for that.
17  the results without need to think optimal view spesific  
18    Motivation
19    ----------
20    
21    Yes, I (*humppake*) believe that the view interface in GZZ 0.8 is much more
22    flexible than the on in 0.6. Although, I worked on 0.8 for weeks, and I
23    still had problems with our coordinate system biased approach for drawing.
24    It's good, but feels too abstract at first sight, since you are used handle
25    only one coordinate system at time.
26    
27    I think there should be easy-to-use interface for prototyping new views.
28    Something with you can start directly by putting some vobs into the space
29    and see the results without needing to think about optimal view spesific
30  coordinate systems first.  coordinate systems first.
31    
32    Current VanishingClient
33    -----------------------
34    
35    In view ``gzz.view.VobVanishingClient`` has been done a lot of work for
36    abstracting some of the general things that view must do - and thus,
37    made them easier to do.
38    
39    - method for placing all vobs using only one coordinate system
40      (without even need to know that other exists), using this was
41      familiar from GZZ 0.6
42    - easy method for creating connections
43    
44    ::
45    
46            /** An interface abstracting some things away from the vanishing view.
47             */
48            public interface VanishingClient {
49                final int CENTER = 1;
50    
51                Object getVobSize(Cell c, float fract, int flags, Dimension into);
52                void place(Cell c, Object o, float fract, int x0, int y0, int x1, int y1,
53                            int depth, float rot);
54    
55                /** There should be a connection between the given cells.
56                 * If one of the cells hasn't yet been placed, this means that
57                 * a stub in that direction should be drawn.
58                 */
59                void connect(Cell c1, Cell c2, int dx, int dy);
60            }
61    
62    .. image:: ../../uml/vanishingview.png
63    
64    Describing shortly (this will be replaced with sequence diagram): VobVanishingClient
65    implements both the View and VanishingClient interface. When its render() is called,
66    it will call PlainVanishing, where the views placing logic is handled. PlainVanishing
67    will then use VanishingClient's abstracted interface for placing cells.
68    
69  Issues  Issues
70  ------  ------
71    
72  ``VobVanishingClient`` seems to have already it own simplified  - Should ViewTool hide the coordinate system biased approach like
73  routines for placing vobs and building connections. Using those in    VanishingClient currently does?
74  ``PlainVanishing`` looks quite nice. So, generalizing ``VobVanishingClient``          
75  would be a good start. So, because ``PlainVanishing`` is a hard coded          RESOLVED: Not. Learning the coordinate system approach is crucial
76  component int ``VobVanishingClient``, I would first make this component          for view development. Though, coordinate system should be easy
77  a parameter for ``VobVanishingClient``'s constructor, interface for the          to use.
78  component, and finally ``PlainVanishing`` only implements that interface.  
79  Looks too simple this far. There must another issues to concern?  - How cells should be placed through ViewTool?
80    
81            The drawing box, cell, its 2D coordinates, depth and
82            scale could be passed to ViewTool's place. It will return
83            an appropriate coordinate system for placing vob self by
84            VobScene's put().
85      
86      - Do we need anymore to get and use Dimension size from VobScene,
87        when we are using box coordinate systems?
88    
89    - How connections should be created through ViewTool?
90    
91    - Do we need rasters in general?
92    
93    - If yes, what rasters should exactly do?
94    
95    - How rasters could be used through ViewTool?
96    
97    - Finally, would using planned methods make e.g. out basic
98      views look more clear?
99    
100    Changes
101    -------
102    
103  Naming issues for above... and UML.  This is currently in very beginning.
104    
105  Probably using the raster could also be made easier or at least  .. image:: ../../uml/viewtool.png
 better documented.  
106    
107    Finally basic views should rewrite using ViewTool.

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

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