[Gzz-commits] gzz/doc/pegboard 1017/PEG_1017.rst 1018/PEG_101...

[Asko Soukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Asko Soukka <address@hidden>    02/10/18 09:14:10

Modified files:
        doc/pegboard/1017: PEG_1017.rst 
        doc/pegboard/1018: PEG_1018.rst 

Log message:
        not much new

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1017/PEG_1017.rst.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1018/PEG_1018.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1017/PEG_1017.rst
diff -c gzz/doc/pegboard/1017/PEG_1017.rst:1.3 
gzz/doc/pegboard/1017/PEG_1017.rst:1.4
*** gzz/doc/pegboard/1017/PEG_1017.rst:1.3      Wed Oct 16 02:15:12 2002
--- gzz/doc/pegboard/1017/PEG_1017.rst  Fri Oct 18 09:14:10 2002
***************
*** 3,10 ****
  =============================================================
  
  :Author:   Asko Soukka
! :Date:     $Date: 2002/10/16 06:15:12 $
! :Revision: $Revision: 1.3 $
  :Status:   Incomplete
  
  The reading depth in ``gzz.view.BFRaster`` is currently a public
--- 3,10 ----
  =============================================================
  
  :Author:   Asko Soukka
! :Date:     $Date: 2002/10/18 13:14:10 $
! :Revision: $Revision: 1.4 $
  :Status:   Incomplete
  
  The reading depth in ``gzz.view.BFRaster`` is currently a public
***************
*** 12,28 ****
  publicity makes it readable from using context, publicity makes
  it also directly writable. Currently writing directly into the 
  attribute from the context is the only way to change raster's reading
! depth.
  
! We could avoid this and use the depth attribute read only as the
! other attributes in raster's by making it a new parameter for 
! ``BFRaster.read()``.
  
  Currently there is a default value for the depth attribute. If
  the new depth attribute is always obligatory the default value
  is never used. Should we add the new attribute by only overloading /
! not replacing the current ''BFRaster.read()'' and make still 
! possible to use the default value?
  
  Changes
  -------
--- 12,34 ----
  publicity makes it readable from using context, publicity makes
  it also directly writable. Currently writing directly into the 
  attribute from the context is the only way to change raster's reading
! depth. Although, writing directly into the attribute is
! deprecated.
  
! Issues
! ------
! 
! We could avoid direct writing and use the depth attribute read
! only (as the other attributes in rasters) by making it a new 
! parameter for ``BFRaster.read()``.
  
  Currently there is a default value for the depth attribute. If
  the new depth attribute is always obligatory the default value
  is never used. Should we add the new attribute by only overloading /
! not replacing the current ''BFRaster.read()'' and make it still 
! possible to use also the default value?
! 
! 
  
  Changes
  -------
***************
*** 38,48 ****
      -    public void read(Cell center, Dim[] dims) {
      +    public void read(Cell center, Dim[] dims, int rdepth) { 
      +            depth = rdepth;
- 
- 
- 
- 
- 
- 
- 
- 
--- 44,46 ----
Index: gzz/doc/pegboard/1018/PEG_1018.rst
diff -c gzz/doc/pegboard/1018/PEG_1018.rst:1.1 
gzz/doc/pegboard/1018/PEG_1018.rst:1.2
*** gzz/doc/pegboard/1018/PEG_1018.rst:1.1      Thu Oct 17 02:14:44 2002
--- gzz/doc/pegboard/1018/PEG_1018.rst  Fri Oct 18 09:14:10 2002
***************
*** 3,24 ****
  =============================================================
  
  :Author:   Asko Soukka
! :Date:     $Date: 2002/10/17 06:14:44 $
! :Revision: $Revision: 1.1 $
  :Status:   Incomplete
  
  Yes, I believe that the view interface in 0.8 is much more
! flexible than the on in 0.6. Although I have been now working
! on 0.8 for weeks, I need still time to get used to those
  coordsys transformations everywhere. I think there should be
! easy-to-use interface for prototyping new views. Something where
! you can start directly putting some vobs into (at least 2D) space
! and see the results without need to think optimal view spesific 
  coordinate systems first.
  
  ``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. Probably using the raster could also be made easier,
! at least better documented.
  
--- 3,35 ----
  =============================================================
  
  :Author:   Asko Soukka
! :Date:     $Date: 2002/10/18 13:14:10 $
! :Revision: $Revision: 1.2 $
  :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
  coordinate systems first.
  
+ 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?
! 
! Naming issues for above... and UML.
! 
! Probably using the raster could also be made easier or at least 
! better documented.