Re: [Gzz] [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java (fwd)

[Tuomas Lukka]

On Fri, Jan 10, 2003 at 09:37:21PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> >>I believe that just giving the color to each vob is really 
> >>straight-forward. 
> >
> >
> >Yes, straightforward, but HORRIBLY CLUTTERY! I don't want every low-level
> >Vob that draws something to have a color parameter!
> 
> As for performance of low-level vobs, I think the most usual case is to 
> have 3 to 6 different colors used for different kinds of vobs, e.g. the 
> lighter and the two darker colors in a 3d rectangle/bevel, the 
> background color for a cell, the default text color, and the window's 
> background color. Example:
> 
>     scene.setColor(white)
>     scene.map.put(background, boxCs)
>     scene.setColor(lightGrey)
>     scene.map.put(upperLine, boxCs)
>     scene.map.put(leftLine, boxCs)
>     scene.setColor(darkGrey)
>     scene.map.put(rightLine, boxCs)
>     scene.map.put(lowerLine, boxCs)
>     scene.setColor(darkerGrey)
>     scene.map.put(rightLine2, boxCs)
>     scene.map.put(lowerLine2, boxCs)
>     scene.setColor(black)
>     scene.map.put(text, boxCs)
> 
>     (repeat for next cell)
> 
> If we have more than one 'foreground color,' we will need to change the 
> AWT/GL state multiple times per cell anyway. (If this takes too long to 
> be done for every vob, the drawing code can remember the last color and 
> change AWT/GL state only if the current vob's color != the last color.)

You're confusing levels here, I think. The above code would be abstracted
to one call

        put3DRect(white, lightGrey, darkGrey, darkerGrey, black)

or alternatively into its own Vob which would worry about it inside itself.

This is NOT the *basic* case I'm talking of.

> As for simplicity of code, I believe things get easier if the views 
> don't have to worry about color for things like borders and cell 
> backgrounds because it will be stored in the vob. I believe that the 
> stateful interface would make *some* sense if we could say:
> 
>     scene.fg = red
>     subView.renderLotsOfThings()
>     scene.fg = black
> 
> but we can't because we need multiple colors *in each cell* (or button 
> or menu item or whatever).

Benja: we're talking past each other. We need to separate the levels.

1) VobScene: low-level API

2) Inside view: using VobScene, putting colors into it

3) Outside view: using view, giving the view the colors as parameters, in 
viewcontext
   or something like that

You're talking as if 3) would use the vobscene API to put the colors in - that's
not the idea here.

> If we could do
> 
>     scene.cellBorderColor = black
>     scene.defaultTextColor = red
>     scene.cellBgColor = white
>     scene.windowBgColor = lightBlue
> 
> things would start to make sense, but that would not be in tune with any 
> efficiency arguments.

These are not aspects of the scene! The vobscene is a LOW-LEVEL construct.
However, putting these into the viewcontext might be a reasonable idea.

        Tuomas