[Gzz-commits] gzz ./TODO doc/pegboard/1018/PEG_1018.rst doc/u...

[Asko Soukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Asko Soukka <address@hidden>    02/12/10 11:06:39

Modified files:
        .              : TODO 
        doc/pegboard/1018: PEG_1018.rst 
Added files:
        doc/uml        : vanishingview.mp vanishingview.uml viewtool.mp 
                         viewtool.uml 
Removed files:
        doc/pegboard/1017: PEG_1017.rst 

Log message:
        sketching ViewTool

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/TODO.diff?tr1=1.444&tr2=1.445&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1018/PEG_1018.rst.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/vanishingview.mp?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/vanishingview.uml?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/viewtool.mp?rev=1.1
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/uml/viewtool.uml?rev=1.1

Patches:
Index: gzz/TODO
diff -u gzz/TODO:1.444 gzz/TODO:1.445
--- gzz/TODO:1.444      Mon Dec  9 17:48:17 2002
+++ gzz/TODO    Tue Dec 10 11:06:38 2002
@@ -190,25 +190,26 @@
        + speed up tests: currently too much execfile().. could
          pre-compile and exec compiled in the same globals().
     humppake:
-       - If OvalBgVob is used as Bg vob it should not use colored
-          sectors:
-            - OvalBgVob to use colored stripes also with AWT
-            - SectorVob for LollipopCV, 360dgrs is a CircleVob :)
-            - SquareVob, square with colored sectors
-           - should these be named ColoredXXXVob?
-           - think about renderables for OpenGL sides, with them
-              dicing and using with distorted coords would be possible :)
+       - write about representing mind map in ZZ
+           - how different dimensions would be used
+           - how n:m associations are handled
+        - rethink View interfaces
+           - PEG1018 - ViewTool
+            - peg about stretching and mounting connections
+       - rename solids into cellColors or something...
+       - Vobs
+            - ColoredSectorVob for LollipopCV, 360dgrs is a CircleVob :)
+            - ColoredSquareVob, square with colored sectors
+           - think, how "solids" could be rendered using renderables 
+              in circular forms, specially stripes in oval could be
+              difficult 
        - opengl demo, which uses view (made in python)
-        - rethink interfaces between PlainVanishing and VobScene
-         eg. correct implementation of LollipopCellView needs
-          to affect connections' coordsys (through box?)
-           - first have to understand current interfaces -> UML
-           - new PEG, new UMLs would be good
-            - also stretching relates this
-           - more about PEG1018 - generalizing VobVanishingClient
+       - new umltool and paper about it
        - BallCellView (text inside the ball)
            - we don't want more complicated line breaker, uses cell's
               content will be in square
+       + create gfx/libirregu from irregu4.py and make effects.py to use
+          new libirregu... ask jvk for more.
        + fix the way nonlinearity of coordsys is handled.
          Needs a slightly better approach, with also 
          direction of nonlinearity taken into account.
Index: gzz/doc/pegboard/1018/PEG_1018.rst
diff -u gzz/doc/pegboard/1018/PEG_1018.rst:1.3 
gzz/doc/pegboard/1018/PEG_1018.rst:1.4
--- gzz/doc/pegboard/1018/PEG_1018.rst:1.3      Thu Nov 14 10:40:07 2002
+++ gzz/doc/pegboard/1018/PEG_1018.rst  Tue Dec 10 11:06:39 2002
@@ -1,35 +1,107 @@
-=============================================================
-PEG 1018: Generalizing VobVanishingClient
-=============================================================
-
-:Author:   Asko Soukka
-:Last-Modified: $Date: 2002/11/14 15:40:07 $
-:Revision: $Revision: 1.3 $
+==========================================================================
+PEG 1018: ViewTool (was generalizing VobVanishingClient)
+==========================================================================
+
+:Author:   Asko Soukka, Benja Fallenstein
+:Date-created: 2002-12-10
+:Last-Modified: $Date: 2002/12/10 16:06:39 $
+:Revision: $Revision: 1.4 $
 :Status:   Incomplete
 
-Yes, I believe that the view interface in 0.8 is much more
-flexible than the on in 0.6. Although I had been working
-on 0.8 for weeks, I still had problems to get used to those
-coordsys transformations everywhere. I think there should be
-easy-to-use interface for prototyping new views. Something with
-you can start directly putting some vobs into space and see 
-the results without need to think optimal view spesific
+This PEG is about creating a ViewTool. The ViewTool would offer easy-to-use
+interface for prototyping new views - and lowering the treshold of starting
+view development.
+
+PS. UML-diagrams are not currently compiled with this PEG, but
+by "make uml", sorry for that.
+
+Motivation
+----------
+
+Yes, I (*humppake*) believe that the view interface in GZZ 0.8 is much more
+flexible than the on in 0.6. Although, I worked on 0.8 for weeks, and I
+still had problems with our coordinate system biased approach for drawing.
+It's good, but feels too abstract at first sight, since you are used handle
+only one coordinate system at time.
+
+I think there should be easy-to-use interface for prototyping new views.
+Something with you can start directly by putting some vobs into the space
+and see the results without needing to think about optimal view spesific
 coordinate systems first.
 
+Current VanishingClient
+-----------------------
+
+In view ``gzz.view.VobVanishingClient`` has been done a lot of work for
+abstracting some of the general things that view must do - and thus,
+made them easier to do.
+
+- method for placing all vobs using only one coordinate system
+  (without even need to know that other exists), using this was
+  familiar from GZZ 0.6
+- easy method for creating connections
+
+::
+
+       /** An interface abstracting some things away from the vanishing view.
+        */
+       public interface VanishingClient {
+           final int CENTER = 1;
+
+           Object getVobSize(Cell c, float fract, int flags, Dimension into);
+           void place(Cell c, Object o, float fract, int x0, int y0, int x1, 
int y1,
+                       int depth, float rot);
+
+           /** There should be a connection between the given cells.
+            * If one of the cells hasn't yet been placed, this means that 
+            * a stub in that direction should be drawn.
+            */
+           void connect(Cell c1, Cell c2, int dx, int dy);
+       }
+
+.. image:: ../../uml/vanishingview.png
+
+Describing shortly (this will be replaced with sequence diagram): 
VobVanishingClient
+implements both the View and VanishingClient interface. When its render() is 
called,
+it will call PlainVanishing, where the views placing logic is handled. 
PlainVanishing
+will then use VanishingClient's abstracted interface for placing cells.
+
 Issues
 ------
 
-``VobVanishingClient`` seems to have already it own simplified
-routines for placing vobs and building connections. Using those in
-``PlainVanishing`` looks quite nice. So, generalizing ``VobVanishingClient``
-would be a good start. So, because ``PlainVanishing`` is a hard coded
-component int ``VobVanishingClient``, I would first make this component
-a parameter for ``VobVanishingClient``'s constructor, interface for the
-component, and finally ``PlainVanishing`` only implements that interface.
-Looks too simple this far. There must another issues to concern?
+- Should ViewTool hide the coordinate system biased approach like
+  VanishingClient currently does?
+       
+       RESOLVED: Not. Learning the coordinate system approach is crucial
+        for view development. Though, coordinate system should be easy
+        to use. 
+
+- How cells should be placed through ViewTool?
+
+       The drawing box, cell, its 2D coordinates, depth and
+        scale could be passed to ViewTool's place. It will return
+        an appropriate coordinate system for placing vob self by
+        VobScene's put().
+  
+  - Do we need anymore to get and use Dimension size from VobScene, 
+    when we are using box coordinate systems?
+
+- How connections should be created through ViewTool?
+ 
+- Do we need rasters in general?
+
+- If yes, what rasters should exactly do?
+
+- How rasters could be used through ViewTool?
+
+- Finally, would using planned methods make e.g. out basic
+  views look more clear?
+
+Changes
+-------
 
-Naming issues for above... and UML.
+This is currently in very beginning.
 
-Probably using the raster could also be made easier or at least 
-better documented.
+.. image:: ../../uml/viewtool.png
 
+Finally basic views should rewrite using ViewTool.