New view system

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

I wrote:
> I have been sick and mainly unable to work on the new view system. I
> know what the main problem is, though: the data structures. Basicly, the
> view system we worked out when I was in Finland is a directed network
> without loops, not a tree-- and I haven't found an efficient way to
> represent that in Java yet. I'm inclined to let the issue rest at the
> moment and write a quick-and-dirty slow-running powerless implementation
> using a mere tree that can be extended later.

The main problem we face is that most vob sets will be very small,
containing only one or a few vobs. This is because in the structure
views, every cell we put on the canvas will have its own vob set; and
this is because we want to be able to show other things than text, and
if text, multiple lines of it, in one cell. Still, we want to use the
same *boxes* for all kinds of things we show in cells. What we do is
creating vob sets (VobBoxes, that is, VobSets inheriting from Vob) and
handing these to the individual views for the cell content.

Now, the worst thing isn't even that we create array objects even for
these very small vob sets. The worst thing is that we don't know how
many vobs will come, and thus have to create new array objects when the
old ones become to small. Thus this approach doesn't work at all. As we
already worked out in January, the solution is to have all vobs stored
in one object, the VobStore, which can also act as the top-level vob
set. But the problem is how to store a directed network efficiently. Now
I've reduced it to a tree for the time being, but that doesn't make the
problem go away, it just makes it easier.

The data structure I'm working on now is as follows. All vobs, including
VobBoxes, are stored in one big array. Now, the vob box is stored
directly before all the vobs in it, and in the vob box object, we have a
member stating its "length," i.e. the number of its direct and indirect
children. Thus, for a vob box with length n and index i, all objects
with i < index <= i+n are children of this vob box.

Of course, vobs are added in order, so you wouldn't be allowed to add
another vob to a vob set after you have added a vob to a higher-level
vob set. Sometimes you will probably want to do that, though. The
solution is simple: Before making any request that is based on the above
data structure, a sort routine is applied.

There's one problem with this though. It would be nice to use the
structure also when drawing, i.e. just sort the elements and draw one
after another. But when drawing, we usually start from the end of the
array: when same depth, the things put first are considered most
important, and are drawn last (on top). But when we start at the end of
the array, we cannot easily see where the scope of a new vob set begins,
i.e. where we need to draw the background of a new vob set. (When we
start at the beginning, we know the "length" of a vob box, i.e. where
the vob box ends, and thus know when to draw that vob box's top frame.)
I'm inclined to go the easy way here, too, and define the behavior so
that things put first are rendered first: usually we use depth anyway,
and when we need to put multiple things at the same depth, but with a
given order among them, we can create an invisible vob box at that depth
and give the individual things different depths again.

So in the first implementations, connections will be the only things
that break the hierarchical boxes. Later I want vobs that are logically
in two vob sets and practically float between them, which requires vobs
to be logically in a number of vob sets, none of which is the one which
actually draws it-- but that's for another time.

- Benja