[Gzz] Asko 2002-12-04/05 (OvalBgVob)

[Asko Soukka]

7h / 11h workdays
 - thought about circular vobs:
   - OvalBgVob works now like RectBgVob as backgroud for content, both
     AWT and GL draws solids (where that term comes from?) as colored
     stripes
   + I'll create ColoredSectorVob and ColoredSquareVob for use with
     ball-and-stick aka lollipop cellview. They show solids as
     colored sectors.
   + I'd like to implement GL side for all of them as renderables
     (and make them dice). Though, I'm not yet sure, how should those
     solids should be handled then. Probably the renderable is only
     a primitive and solids are created on the Java side. E.g.
     one solid is created as a colored and clipped part of the renderable.

 - Discussed with Benja about making creating views easier. Benja
   proposed creating some kind of ViewTool, which abstracts view's tasks
   a litte like VanishingClient does, but more coordsys centered. So,
   we don't hide coordsys', but make them easier to use. Eg. ViewTool's
   place doesn't truly place vob, but returns a coordsys for true placing.
    + Current views should be reimplemented using this ViewTool
      afterwards to make them look cleaner and easier to understand.
    + Rasters are still an open question. How should they work, could
      they be flexible enough for most of the views, how repeating cells
      should be handled (e.g. to draw connections correctly), how
      rasters could be easy to use enough (current BFRaster is not
      clear at the first sight :).

 - We discussed also about the problem, how connection could be drawn
   differently in LollipopCV and BoxCV. Came up that the same problem
   exists also with TDecoder. We ended up with solution, where View
   queries the connection/Tdecoder vob for spesific angle from CV.

 - Finally, Tuomas asked my interest for enhanching current documl tool
   and trying to write an article about it:
   + at first architecture htmls should be replaced with rst's, for
     reST this needs our own UML-directives.
   + at the beginning of UML-diagram should be a link list for all reST
     (architecture and peg) pages where diagram is included
   + the diagram should be included in every documenet where it links to
   + finally the diagram should be 'personalized' for document where
     its included (explicitly or implicitly by this script)
     + the current document should be focused by coloring (and maybe
       later with zooming) in included diagrams, here this gets
       interesting :)

   I would be interested enough, if I'm allowed to extract a fully GZZ's
   cvs independent tool from this. Since everything is LGPL, this
   shouldn't be a problem - needs only a little more time. What this needs
   is at least some kind of config and listing all dependencies (javadoc,
   (docxx,) metapost, docutils). Probably uml.py and uml-helper.mp should
   be also documented little more :) My motive is that I could easily
   use these tools also with other projects than gzz afterwards. And if it
   gets good enough, probably someone elso wants also...

   What would be the targets of the paper?
    - using several doc tools serially together for synergy
    - embedding architectural diagrams (also within the
      documentation of single components to show their using contexts)
    - bidirectional linking within documentation (also within
      documentation created using different tools)
    - focus+context in diagrams
    (- how all this should come naturally in GZZ ;)

-- 
Asko Soukka     | Taitoniekantie 9 A 603 | address@hidden
+358-40-8235947 | FIN-40740 JYVÄSKYLÄ    | http://www.iki.fi/asko.soukka/