Re: [zzdev] Re renderinfo drawing boxes

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> > > Hmmm... Issues are:
> > > * Should renderinfo really draw the boxes itself?
> > 
> > That's the default implementation so I don't have to copy the code
> > to both Trivial and SimpleVobSet.
> > 
> > Note that the method is not final: it can be overridden by something
> > that calls the theme-appropriate routine.
> 
> The question is whether *that* should be the default implementation so
> you don't have to copy the code to both Trivial and SimpleVobSet.

Oh, feel free to change it. It's just a placeholder.

> > > * At some point I want to experiment with connections rendered between
> > > background and box. Then we probably need a different model.
> > 
> > I still think that this has enormous problems. It gets very difficult
> > to make it consistent when nearby, overlapping cells are connected.
> > 
> > Probably an alpha channel approach would work better there.
> > 
> > Or overlying translucent things.
> 
> This does not solve the problem, it just makes it a bit less obvious.
> (Play a case that doesn't work with the one model through with the other
> model. Most work in neither.) That suggests that the underlying model is
> not right. We cannot fix that now, but we should get back to it sometime.

Or the problem is with the inconsistency of what you are trying to do.
Essentially, you want

	1) Reasonable depth-ordering:
		- the box is at the same depth as the content
	2) The connection between the box and the content
		- still fine
	3) different connections meeting
		- here: this is actually impossible to do consistently
		  with 1) and 2).

> > > * The box used may affect the visual center of the vob, as in
> > > ball-and-stick, and thus change the ways views and decorations behave.
> > 
> > No, the box shouldn't. Ball and stick is different in many ways from
> > the normal box stuff. I don't think that the same code can be used.
> 
> Then abstracting the boxes out does not have any use at all. It just
> allows for different themes, which aren't essential at this stage of
> development. If you really think that ball-and-stick should be done
> somehow differently, I suggest you come up with a way for that, we
> implement that, and remove all the current box code.

Oh, *that*'s why you want the box code?

Hmm... this needs some thought. The problem is that basically *everything*
underneath the level of the ball&stick vob needs to know that it should
e.g. paint a shadow or border in order to be visibly clear.

	Tuomas