[Gzz-commits] gzz/doc/pegboard/vob_colorable--humppake peg.rst

[Asko Soukka]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Asko Soukka <address@hidden>    03/03/10 09:50:49

Modified files:
        doc/pegboard/vob_colorable--humppake: peg.rst 

Log message:
        twid

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/vob_colorable--humppake/peg.rst.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/vob_colorable--humppake/peg.rst
diff -u gzz/doc/pegboard/vob_colorable--humppake/peg.rst:1.1 
gzz/doc/pegboard/vob_colorable--humppake/peg.rst:1.2
--- gzz/doc/pegboard/vob_colorable--humppake/peg.rst:1.1        Mon Mar 10 
08:28:25 2003
+++ gzz/doc/pegboard/vob_colorable--humppake/peg.rst    Mon Mar 10 09:50:48 2003
@@ -5,8 +5,8 @@
 :Authors:   Asko Soukka
 :Stakeholders: Benja Fallenstein, Tuomas Lukka 
 :Date-created: 2003-03-05
-:Last-Modified: $Date: 2003/03/10 13:28:25 $
-:Revision: $Revision: 1.1 $
+:Last-Modified: $Date: 2003/03/10 14:50:48 $
+:Revision: $Revision: 1.2 $
 :Status:   Current
 :Scope:    Trivial
 :Type:     Feature
@@ -14,12 +14,12 @@
 This PEG proposes creating **Abstract ColorableVob** class, which
 implements a new **Colorable interface** also defined by this PEG.
 
-**Colorable Vob** is a very basic vob type, which enhances the Vob
-with interface for placing multiple solid colors on it background. The
-multiple solid colors are used a lot in basic Views i.e. to show
-cursor location and node properties. In current implementations
-multiple solid colors are shown as parallel vertical stripes or
-sectors.
+**Colorable Vob** is a very basic vob type, which enhances the regular
+Vob with interface for placing multiple solid colors on its
+background. The multiple solid colors are used a lot in basic views
+i.e. to show cursor location and node properties. In the current
+implementations multiple solid colors are shown as parallel vertical
+stripes or sectors.
 
 This PEG replaces the older `PEG for Abstract Background Vob`__.
 
@@ -32,26 +32,26 @@
 - Why is Abstract Colorable Vob needed?
 
   RESOLVED: Currently there is no common interface for multiple solid
-  colors in node vobs, but they are defined and implemented from the scratch 
in 
+  colors in vobs, but they are defined and implemented from the scratch in 
   every background vob (starting from ``RectBgVob``). A common interface is
-  necessary when that a single node view could select between multiple 
different
-  background vob types depending on nodes' content; the same node view could 
place
-  different vob depending on the node's content.
+  necessary when a single node view that supports solid colors, should
+  select between multiple different background vob types (basing the
+  selection i.e. on nodes' content).
 
 - Why was the PEG for Abstract BackgroundVob declared irrelevant?
 
   RESOLVED: It was about to propose such interfaces for background
   vobs, which would have made them strongly mutable. It was also
-  criticized to restrict background too much by forcing them to have
-  border and background color properties.
+  criticized to restrict background vobs too much by forcing them to
+  have border and background color properties.
 
 - Should Colorable Vob be immutable?
 
   RESOLVED: Yes. The current multi-color implementation in
-  ``RectBgVob`` and other background vobs have been made them mutable.
+  ``RectBgVob`` and other background vobs have made them mutable.
   Inheriting those multi-color features from Colorable Vob should turn them
   back to immutable. Immutability allows storing created vob objects,
-  re-using them and finally enhancing the performance.
+  re-using them and finally enhancing the overall performance.
 
 - How is Colorable Vob related to background vobs?
 
@@ -60,7 +60,7 @@
   immutable and use the common interface for multiple solid colors;
   They should be inherited from ``AbstractColorableVob``.
 
-- How should ColorableVob be assembled?
+- How should Colorable Vob be assembled?
 
   RESOLVED: ColorableVob extends the basic Vob class and implements
   Colorable Interface for multiple background colors.
@@ -68,7 +68,7 @@
 - How should the new interfaces and classes be named?
 
   RESOLVED: **public interface Colorable** and **public abstract class
-  ColorableVob**.
+  ColorableVob**
 
 - Where they should be located?
 
@@ -76,20 +76,13 @@
   (``gzz.vob.Colorable`` and ``gzz.vob.ColorableVob``. Probably in the
   future they will be moved into package ``org.libvob.vob``.
 
-- How should the common features of current background vobs be
-  splitted between Background Interface and Colored Interface?
-
-  RESOLVED: Methods for single color backround and border will be
-  defined in Background Interface and methods of multiple
-  background colors in Colored Interface. The AbstractBgVob will
-  contain the default implementations for them.
-
 - How should *solids* be renamed?
 
   RESOLVED: Earlier, *cellColors* has been proposed. Although, we are
   currently moving away from *cells* to *nodes*. Therefore *solids*
-  should be called simply **colors**. Note that already the method
-  adding them has been called *addColor*.
+  should be called simply **colors**. Note that the method
+  adding them in the current implementations has been called
+  *addColor*.
 
 - How should we store colors?
 
@@ -99,12 +92,12 @@
 - How should the colors be set?
 
   RESOLVED: Since Colorable Vob should be immutable, colors
-  could be added only by cloning a new vob. This methdo would prefer
+  could be added only by cloning a new vob. This method would prefer
   setting all the colors at once as a single List.
 
 - Should SolidBgVob be inherited from Colorable Vob?
 
-  RESOLVED: No. ``SolidBgVob`` is not such background vob than other
+  RESOLVED: No. ``SolidBgVob`` is not a such background vob than other
   BgVobs (``RectBgVob`` and ``OvalBgVob``). More prefarably, SolidBgVob
   should be renamed to avoid misunderstandings.
 
@@ -167,6 +160,6 @@
  - ``gzz.vob.vobs.RectBgVob``
  - ``gzz.vob.vobs.OvalBgVob``
 
-**Cell Views** and **Node Views** will be broken after this change,
-since background vobs' addColor interface will be removed to make vobs
-immutable.
\ No newline at end of file
+**Cell Views** and **Node Views** will be broken (and hast to be
+fixed) after this change, since background vobs' addColor interface
+will be removed to make vobs immutable.