[Gzz-commits] gzz ./TODO ./TODO-uml doc/pegboard/1018/PEG_101...

[Asko Soukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Asko Soukka <address@hidden>    03/02/25 07:02:51

Modified files:
        .              : TODO TODO-uml 
        doc/pegboard/1018: PEG_1018.rst 
        doc/pegboard/textstyle_getwidth--humppake: peg.rst 

Log message:
        twid

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/TODO.diff?tr1=1.595&tr2=1.596&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/TODO-uml.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1018/PEG_1018.rst.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/textstyle_getwidth--humppake/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gzz/TODO
diff -u gzz/TODO:1.595 gzz/TODO:1.596
--- gzz/TODO:1.595      Mon Feb 24 11:29:56 2003
+++ gzz/TODO    Tue Feb 25 07:02:49 2003
@@ -127,41 +127,36 @@
        + speed up tests: currently too much execfile().. could
          pre-compile and exec compiled in the same globals().
     humppake:
-       - 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 :)
+        - rethink View package interfaces
+            - PEG about stretching
+              - stretching vobs suitable for their contents' size
+               - the idea is to request (view requests) the size from 
+                  the cell view, then place the box coordsys, then let
+                  the cell view place itself into that box.
+                - The cell content view has a minWidth, minHeight,
+                  maxWidth and maxHeight computed somehow.
+                - we return at least (minWidth, minHeight).
+                - If that doesn't suffice, we scale horizontally up to 
+                  (maxWidth, minHeight). If that doesn't suffice either, 
+                  we use maxWidth and scale vertically up to maxHeight.
+               + aspect ratio for squares? 
+           - is there need foor ViewTool (PEG1018)
+              and _what_ it should do
+            - PEG about mounting connections
+           - think, how stripes would be rendred in oval renderable
+       - finish python opengl demo for prototyping views
+       - port Mind* views from 0.6
             - 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)
-       - 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.
-       + port Mind* views from 0.6
-       + stretching vobs suitable for their contents' size
-         - the idea is to request (view requests) the size from 
-            the cell view, then place the box coordsys, then let
-            the cell view place itself into that box.
-          - The cell content view has a minWidth, minHeight,
-            maxWidth and maxHeight computed somehow.
-          - we return at least (minWidth, minHeight).
-          - If that doesn't suffice, we scale horizontally up to 
-            (maxWidth, minHeight). If that doesn't suffice either, 
-            we use maxWidth and scale vertically up to maxHeight.
-         + aspect ratio for squares? 
-       + new PEG for bubbleview, with some sketches
-         + 2D / 3D versions, "cell clusters",
-           "surface tension", animation, calibration
-       + benchmark line broking (in LinebrokenCellContentView)
+       + write about representing mind map using RDF
+           + what different properties would be used
+       + Bubbleview, with some sketches
+            + BallCellView (text inside the ball)
+             + we don't want more complicated line breaker,
+                cell's content will be in square within circle
+           + 2D / 3D versions, "cell clusters",
+             "surface tension", animation, calibration
+       + benchmark line breaking (in LinebrokenCellContentView)
     tjl:
        - the great buoy redesign
            - painting the squares with mouse and send coords to console 
Index: gzz/TODO-uml
diff -u gzz/TODO-uml:1.2 gzz/TODO-uml:1.3
--- gzz/TODO-uml:1.2    Mon Feb 24 16:42:33 2003
+++ gzz/TODO-uml        Tue Feb 25 07:02:49 2003
@@ -1,21 +1,53 @@
 Tasks for navidoc
 
+0.1alpha1: First separate release
     humppake:
-        - classify following between the first and second release, 
-          priorize etc...
-       - PEG the new architecture
+       - administrative issues for separating this to
+          distinct project
 
-        ...
-       - document our UML software (metacode/uml*, used by doc/uml/*)
+    anybody:
+       - document our current UML software
+          (metacode/uml*, used by doc/uml/*)
         - figure out need of restructuring
+       - PEG the new architecture
+        - debug class for handling screen output and logging
+          - write all errors and warnings in some place so it's easy to
+            look for them and fix. Current output is incredibly bogously
+            spewy.
 
-       - rationalize doc directory structure:
-          !! Depends on pegboard upgrade for simply compiling of 
-             deep tree structure !!
-         Gzz_Frontend_View.rst -> doc/frontend/View.rst
-         (i.e. no Gzz_ prefixes, tree structure explicit)
+0.2alpha1: Rewriting
+    vegai:
+        + Download new and clean Docutils CVS snapshot, check the
+          problems when importing it in Jython
+          + some fatal errors
+          + harmless SyntaxWarning, but could it still be removed
+
+    anybody:
+       Design issues
+       -------------
+           
+        - plugin issues
+         - make sure that umltool works also with pure doccxx
+         - nested classes in javadoc: grep for MipzipLoader.Level 
+         - Currently diagrams are embedded into html-documents after
+            the first header-tag. This could be enough for javadoc and
+            other, but in reST this should be possible to overdrive by
+            own directive.
+         - unit test plugin
+        - directive issues
+         - diagram names should be unique, currently this can't be
+            easily tested, make something for it
+          + Highlighting should be optional. This should be in UML source,
+            but it could also be added there from an optin of UML directive.
+            Anyway, implementing is not trivial, since even the same png
+            diagram could be used in all documents, the imagemap should 
+            always be regenerated. So, two points:
+            - all refers to the same diagram should use the same png
+            - still every document needs own imagemap
+            - there should be no highlighting
 
-        UML language:
+        UML language
+       ------------
 
        - fix umltool graphics to be closer to the UML 3amigos books
        - Fix UML sequence diagram: now you have to put
@@ -31,57 +63,30 @@
                dep "calls" BuoyLinkListener
          because inside class, the class is given as the 1st argument.
 
-       Design issues:
-           
-       - make sure that umltool works also with pure doccxx
-          => doc++ plugin
-       - nested classes in javadoc: grep for MipzipLoader.Level 
-         => issue of javadoc plugin
-
-       - Currently diagrams are embedded into html-documents after
-          the first header-tag. This could be enough for javadoc and
-          other, but in reST this should be possible to overdrive by
-          own directive.
-       - diagram names should be unique, currently this can't be
-          easily tested, make something for it
-        + Highlighting should be optional. This should be in UML source,
-          but it could also be added there from an optin of UML directive.
-          Anyway, implementing is not trivial, since even the same png
-          diagram could be used in all documents, the imagemap should 
-          always be regenerated. So, two points:
-          - all refers to the same diagram should use the same png
-          - still every document needs own imagemap
-          - there should be no highlighting
-
-0.1alpha1: First separate release
-        - debug class for handling screen output and logging
-          - write all errors and warnings in some place so it's easy to
-            look for them and fix. Current output is incredibly bogously
-            spewy.
-
-0.2alpha1: Rewriting
-    vegai:
-        + Download new and clean Docutils CVS snapshot, check the
-          problems when importing it in Jython
-          + some fatal errors
-          + harmless SyntaxWarning, but could it still be removed
-
-    anybody:
-        pegboard:
-
+        pegboard
+       --------
        - pegboard should be made work fully as reST directive
           + after this all reST-files could be compiled from the root
             using $(JYTHON) metacode/umldoc.py `find doc -name "*.rst"`
-       + clean pegboard.py (= make more oo, since Python is oo language)
-
-        rest -> latex:
+       - util to create new peg
+          - creates directory
+          - add formal header
+          - probaly also template with recommended sectinos
+       - rationalize doc directory structure:
+          !! Depends on pegboard upgrade for simply compiling of 
+             deep tree structure !!
+         Gzz_Frontend_View.rst -> doc/frontend/View.rst
+         (i.e. no Gzz_ prefixes, tree structure explicit)
 
+        docutils latex writer
+       ---------------------
        - cleanup
        - strip all unnecessaries, if there's any
-       - collect comments and experiences of used when
+          - latex output should be as clean and readable as possible
+          - should not have dependecy for unnecessary latex packages
+       - collect comments and experiences of using when
           writing the article
-       ...
-
+       - summarize, what have been changed to the original latex writer
 
 1.0: Feature-complete
     anybody:
@@ -95,5 +100,4 @@
            - fast and easy to use and libre
        - figure out metapost tfm files; we need to have Helvetica.tfm
          since we want to use the postscript font names to get standalone
-         files. But it would be nice not to have it in every directory ;)
-
+         files. But it would be nice not to have it in every directory ;)
\ No newline at end of file
Index: gzz/doc/pegboard/1018/PEG_1018.rst
diff -u gzz/doc/pegboard/1018/PEG_1018.rst:1.7 
gzz/doc/pegboard/1018/PEG_1018.rst:1.8
--- gzz/doc/pegboard/1018/PEG_1018.rst:1.7      Sat Feb 15 01:49:00 2003
+++ gzz/doc/pegboard/1018/PEG_1018.rst  Tue Feb 25 07:02:50 2003
@@ -1,16 +1,18 @@
 ==========================================================================
-PEG 1018: ViewTool (was generalizing VobVanishingClient)
+PEG 1018: ViewTool
 ==========================================================================
 
 :Authors:   Asko Soukka, Benja Fallenstein
 :Date-created: 2002-12-10
-:Last-Modified: $Date: 2003/02/15 06:49:00 $
-:Revision: $Revision: 1.7 $
+:Last-Modified: $Date: 2003/02/25 12:02:50 $
+:Revision: $Revision: 1.8 $
 :Status:   Incomplete
+:Scope:    Minor
+:Type:     Feature
 
 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.
+development of new view.
 
 Motivation
 ----------
@@ -124,29 +126,33 @@
 
 - How cells should be placed through ViewTool?
 
-       The drawing box, cell, its 2D coordinates, depth and
+       RESOLVED: 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().
+
+        ``int placeCS(Box box, Cell cell, float x,
+        float y, float depth, float scale);``
+       
+       X and Y are coordinates of origo of the drawn vob. This
+        way works with both: views that allow stretchable vobs
+        and views that do not.
   
   - 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?
+- Should basic views be rewritten using ViewTool?
+
+- Is ViewTool only obvious shortcuts to add inside VobCoorder or VobScene?
 
 Changes
 -------
 
-This is currently in very beginning.
+This is currently in its very beginning.
 
 .. UML:: umltool
 
Index: gzz/doc/pegboard/textstyle_getwidth--humppake/peg.rst
diff -u gzz/doc/pegboard/textstyle_getwidth--humppake/peg.rst:1.1 
gzz/doc/pegboard/textstyle_getwidth--humppake/peg.rst:1.2
--- gzz/doc/pegboard/textstyle_getwidth--humppake/peg.rst:1.1   Mon Nov 25 
23:45:03 2002
+++ gzz/doc/pegboard/textstyle_getwidth--humppake/peg.rst       Tue Feb 25 
07:02:51 2003
@@ -4,9 +4,9 @@
 
 :Authors:      Benja Fallenstein, Asko Soukka
 :Date:         2002-11-26
-:Last-Modified:        $Date: 2002/11/26 04:45:03 $
-:Revision:     $Revision: 1.1 $
-:Status:       Incomplete
+:Last-Modified:        $Date: 2003/02/25 12:02:51 $
+:Revision:     $Revision: 1.2 $
+:Status:       Irrelevant
 :Scope:                Minor
 :Type:         Interface