Re: [zzdev] Re: [zzdev] Re: Two hashtables per cell? No way!

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> > 
> > Not necessarily a ZOb: the
> > 
> >         ZZLanguage.getLanguage(ZZCell c)
> > 
> > can see along d.lang-prefs whether there is anything: if nothing, return a
> > ZZDefaultLanguage object, otherwise the ZZPrefLanguage object.
> 
> Yes, but if we use the same structure as with views and cell views,
> users can rotate through different language prefs like through the
> views, instead of introducing some other, new way to handle stuff.

Yes and no; the ZOb structure is appropriate for some things but the
language prefs is simply a list of cells. Since this *is* ZigZag, forcing
everything to be ZObs would go against the grain - the DimLists is not
Zobs. How about (* = cell that names the langlist)


	Translations -  *  
                        |
                        * - de - fr - *
                        |
                        * - fi - *
                        |
                        * - en - *  (in case some cells not by default
english)



> So when you have edited in Default, and now want to translate to
> Finnish, you rotate to a language view which shows Finnish if available,
> and Default if not, and which changes to view Finnish when you enter
> text. When you're done with that, you rotate to a language view which
> shows Default if available, and searches the other languages if not...
> well, you get my point.

We'll really need a good mechanism to show that a given language has not
been updated after the default has been updated.

> By the way, I'd say we should call the whole thing a "Texter," because
> it's useful beyond the scope of languages: e.g., you could have a texter
> which shows the content of a cursor's accursed cell in the cursor cargo
> cell -- that's something I'd like to have in the Flowing Clang
> structural debugger (when viewing the stack frames).

That's something we may want to see in several places. But whether that
functionality belongs to the texter or whether you might also want to see
the colors &c or mark it differently so that it would belong into a
different cellview is not clear.

> > > And: how are the languages stored in the structure:
> > > i) on d.language/d.language-alt?
> > > ii) on d.content-en, d.content-de, d.content-fi, d.content-fr ... ?
> > > iii) in some other scheme?
> > 
> > My preference would be for d.translations, as then you'd see the whole
> > rank of the translations in all languages easily.
> > 
> > But that's not yet a strong point; if you can think of any for the other
> > systems, do tell.
> 
> Well, how would we assign languages to cells? What I can think of is
> having a separate cell on d.language denoting the language -- but that
> would, as I said, be quite wasteful in space.

No no, as headcells and intersections. The intersection between the ranks
of translations of a cell and all cells in the given language.

This is currently slow but can be made faster.

Hmm, maybe not such a good idea right now, since we haven't got the code
to make intersections fast.
 
> > > And: should I revert back the changes that pass the window cell to the
> > > cell views? (If not, I'll have to make them everywhere, so that we can
> > > get rid of the old way to call them.)
> > 
> > Where is that change?
> 
> In myCellView.makeFlob(...), the window cell is given now; it didn't use
> to be passed on. Obviously, this means every view which uses the cell
> view given to it to place flobs needs to be updated to the new calling convention.

Hmm... I'd prefer to do it when creating the flobs. Check whether

	if(zzlanguage != null && zob instanceof ZZLocalizable)
		((ZZLocalizable)zob).setLanguage(zzlanguage);

in ZZDefaultSpace.getScene(). This works for both the raster and the
cellview. And the default language would always be

	ZZLanguage.default

which is quick to assign to the member originally so if zzlanguage is null
we save stuff. So getLanguage should return null if no language is given.

Actually, maybe even give it to newZOb --- not yet, but later?

> > But ii) is a good alternative, too.
> 
> So, my points said, which one do you want?

I'm still not sure. Maybe we should just try one first.

	Tuomas