Re: [zzdev] Re: [Gzigzag-commits] gzigzag/Java/flob FTextLayouter.zob SimpleTextView.zob

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> It's really a case where hierarchies just do not work.

Right.

> > What I'm thinking of now is a recursive flobset API where you can ask it for
> > a subflobset, etc.
> 
> Good idea. Problem: how to get the depth right. We want to be able to
> say "I'd like a subflobset at depth 7," then place elements in that
> subflobset with depths ranging from 5 to 15, then have them drawn after
> everything of depth 8 and before everything of depth 6 in the master flobset.

I figured out a solution to this: we use absolute coordinates for EVERYTHING.

That means that views that get called as parts of other views need to be aware
of their coordinates but on the other hand, it gives everyone a great deal
more freedom.

> > The biggest problem, I guess, is defining exactly what kinds of searches we
> > want to put in there for different things.
> > 
> > I'd say:
> > 
> > 1) definitely "(nearest) flob for this cell in this flobset", returning
> >    exactly one flob
> > 
> >         - what to do about several flobs for a cell? In this model,
> >           that would only happen for loops in e.g. the hard rasters.
> >           The dimension-showing cells would be in a different flobset
> >           so they wouldn't be a problem.
> >         - maybe the hard rasters shouldn't rely on stdlinks but draw the
> >           connections themselves? That would actually make some sense...
> 
> I think it would limit us too much if the hard rasters would remain the
> only ones which can repeat cells. If you create complex structures with
> many "paradoxical" connections, e.g. tables with their columns sorted,
> you basicly cannot use vanishing right now, but it would be nice to be
> able to use it. Grid views with soft rasters, too.
>
> To me, not repeating a cell when you encounter it a second time is a
> special mode because it only works with *very few* of all conceivable
> structures. Granted, lists and trees are what we're using now mainly,
> but tables and networks (trees where nodes can have more than one
> parent) are almost equally important. And we do not want to get locked
> up in plain old Euclidean tables because we cannot view others.

The issue is not repeating the cell, really. That's something that will be 
allowed.

The issue is searching for flobs by cells. Which flob or flobs should
be returned.

> So even while I see that most cells will be shown only once, and thus
> this should be the efficient case, I think it would be totally wrong to
> build a model in which a cell *can* only be shown once and adding a few
> exceptions to that. That would lock us up because it would render more
> complex structures unusable. 
> 
> Well, stdlinks doesn't do its job right with repeated cells, so we do
> need a solution for that. Maybe saving in the flobs what they're
> supposed to be connected to?

Those connections can be drawn at the same time the flobs are placed.
The real problem is the other connections: if there is a repeating
structure, the structure of the links should repeat too.

> > 2) the SpanFlobs overlapping this span in this flobset
> 
> Right, that would be nice.
> 
> > 3) flobs corresponding to given cell anywhere
> > 
> > Hmm? We need to hash this out a little more.
> 
> I'm actually not sure of anything right now. :o/ This will probably
> require a lot more attempts until we have a more or less generally
> usable system.
> 
> > I'm thinking right now mostly of several nile streams being shown at once, which
> > is a more difficult model than we have now, as e.g. page up and page down would
> > require finding out what the lowest displayed part of this stream is...
> 
> Yep. I'd also like up and down go to the next and previous line, which
> is a similar problem...

Actually, one possibility is that up and down use the next largest unit: words for
letters, sentences for words etc. 

It has its good and bad points...

But yes, for up and down to work conventionally, we need the same ability, or
basically saying "this is one single stream, all these flobs".

	Tuomas