Re: [zzdev] src/core, Vobs

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Rauli Ruohonen wrote:
> Then there is the Vob stuff. I think Benjamin knows the most about these,
> so perhaps I shouldn't meddle with it?

Currently, I can't realize my earlier draft, because I can't get the
data structures right. The most pressing need for it though, nesting
views, is now possible through the SceneFlobs, thankfully.

I suppose we'll go through some more iterations until we arrive at a
reasonable system which does the things we need to do. It'll be good if
we experiment a bit, e.g. with what you describe.

> - The Vob class should be simple, not knowing about its absolute location,
>   etc. Just a "visual object" = a hyperbox (rectangle or box in practice :-)
>   with content. It should be able to draw itself, but not know anything
>   about interpolation (just draw() and drawFast()). Vob can draw itself,
>   if it is given the absolute hypercube it should fit itself into (thus
>   taking care of both translation and scaling, enough for interpolation).

Uh, the vob is only responsible for drawing the content; the boxes are
drawn by another object (BoxType). The only thing current BoxedFlobs do
related to their boxes is remembering their background colors. And most
current contents are textual; and we don't scale text at the moment. So
there isn't much scaling to do (clipping, though).

I mostly do not see why this would be a simplification; it would move
the complexity to the structures above, so what would we gain? There's
one very good thing about it, but that wouldn't be a simplification.
It's that Vob objects would be re-usable in different VobSets (namely,
one we interpolate from and one we interpolate to). If we _would_ do
some sort of text scaling in vobs, and if we would store the coordinates
of vobs as floating point numbers which are then multiplied with the
actual size of the VobSet, we could re-use subviews in higher-level
views (re-using the vob objects). But that, though it *might* make
things faster, would also increase the complexity of the system.

> - When interpolation begins, just split the Vobs if we wouldn't otherwise
>   get a 1-to-1 correspondence.

That means making vobs more complex again. Do you have an interface in
mind that makes splitting possible?

> It should be added that there are two ways of constructing Vob structures:
> top-down, where the absolute hypercube is given and the vobs should be fit
> into it, and bottom-up where the Vobs are just constructed and then
> translated & scaled to the correct place. Both should work, otherwise
> things will be inconvenient.

I don't understand this. Could you try to re-phrase?

> These are just stray thoughts and mostly obvious. IIRC, the Vob/VobBox
> thingy did sound much like this -- am I right?

No, the important parts of that system were:
1) nesting views, by nesting VobSets, realized through a VobStore which
stores the vobs for a whole tree of VobSets;
2) drawing connections between nested views. (I can't get the data
structures right for the plan here, but I'll experiment with the
Connector2D stuff.)

Hm, actually, 1) might be realizable; it'll be worth a try with the new APIs.

-b.