gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] PEG ``vob_bgvob--humppake``: Background Vob interface


From: Tuomas Lukka
Subject: Re: [Gzz] PEG ``vob_bgvob--humppake``: Background Vob interface
Date: Wed, 5 Mar 2003 20:14:52 +0200
User-agent: Mutt/1.4i

On Wed, Mar 05, 2003 at 06:14:01PM +0200, Asko Soukka wrote:
> =====================================================
> PEG ``vob_bgvob--humppake``: Background Vob interface
> =====================================================
> 
> :Authors:   Asko Soukka

Very good that you're doing a PEG of this - and the idea seems
great as well. Below are some comments.

> :Stakeholders: Benja Fallenstein, Tuomas Lukka 
> :Date-created: 2003-03-05
> :Last-Modified: $Date: 2003/03/05 16:12:13 $
> :Revision: $Revision: 1.1 $
> :Status:   Current
> :Scope:    Trivial
> :Type:     Feature
> 
> This PEG proposes of creating **Background Vob interface**, which at
> first includes the border flag and color handling originally made for
> ``RectBgVob``. The new interface allows the easy use of different
> (*Background*) Vobs in a single View.

Would be best to say in the abstract *what* a background vob is -- it
doesn't come quite clear from the above.

> Issues
> ------
> 
> - How interface should be named?
> 
>   RESOLVED: Interface ``BgVob``
>
> - Where it will be located?
> 
>   RESOLVED: Currently at ``gzz.vob.BgVob``, probably in the
>   future at ``org.libvob.vob.BgVob``.
>
> - What should interface ``BgVob`` contain?
> 
>   RESOLVED: At first it should containt the handling of background 
>   color and *solid colors* from ``RectBgVob``. Those are currently
>   also copied to ``ColoredSectorVob``.

RESOLVED: should *always* include the *reasons* for resolving it a 
particular way.

> - How should *solids* be renamed?
> 
>   RESOLVED: *cellColors* has been proposed, but now we are
>   moving away from *cells* to *nodes*. Therefore *solids* could
>   be called simply *colors*. Already the method adding them
>   have been called *addColor*.
    ^^^^^^^^^
      is

Either "is called" or "has been named".

> - Should we use an *array* or *Vector* to store *colors*?
> 
>   RESOLVED: We should use ``java.util.Vector`` if it's performance
>   is not a problem. Currently ``RectBgVob`` uses array and resizing
>   it needs additional work. Also those AWT tools, which have used Vobs'
>   ``java.awt.Color`` arrays are already moved to ``basalt``. Though, the
>   content of vector could still be passed on in an array.

I think this is probably not right; Vector is the 1.1 old API. List is
the modern Collections API with several improvements.

> Changes
> -------
> 
> Interface BgVob with following attributes and methods will
> be created::
> 
>     /** Flag for drawing border. */
>     public boolean drawBorder = true;


>     /** Vector to store Colors. */
>     protected Vector colors = new Vector(5, 5);
>       
>     /** Background color of the Vob */
>     protected Color bg = Color.white;

How do you put these in an interface? These are more implementation,
aren't they? Maybe you want "interface BgVob" and "abstract class 
AbstractBgVob"?

>     /** Set the background color of the Vob */
>     public void setBg(Color c){ if( c != null ) bg = c; }
> 
>     /** @return the background color of the Vob */
>     public Color getBg() { return bg; }
> 
>     /** Adds one more color to be drawn inside the Vob. */
>     public void addColor(Color c) {
>       if (Color != null) colors.addElement(c);
>     }
> 
>     /** The currently put node colors.
>      * @return an array of Colors or null if no colors is set. 
>      */
>     public Color[] getColors() {
>       if (colors.size() == 0) return null;
>         Color[] c = new Color[colors.size()];
>       for (i=0; i<colors.size(); i++)
>           c[i] = (Color)colors.elementAt(i);
>       return c; 
>     }
> 
> Current vobs should be changed to implement this interface
> (``RectBgVob`` and ``ColoredSectorVob``). Also many other Vobs should
> be changed to use a new Color Vector instead of old *nsolids* color
> counter and *solids* Color array. No ``CellViews`` or ``NodeViews``
> should be broken after this change, since RectBgVob's addColor
> interface remains same. Although, at least Loom's ``NodeViews`` should
> be build using ``BgVob`` instead of ``RectBgVob`` or any other particular
> Vob.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]