[Gzz] (Lately)

[b . fallenstein]

Hi all,

here's my report for "lately," as well as a request for Tuomas.

What I've done:
  * Bugfixes to VobScene and binders
  * Implement basic text edit in Fallback
  * Implement connections in Fallback
  * Restructured views
  * Foundations for line cursors

Restructured views: I've made View and FallbackView into one class (View) by
introducing the ViewContext abstraction, allowing you to retrieve stuff like
the cursor position and the dimension set-- that can be implemented reading
that from the structure or from a Java object.

Foundations for line cursors: Text edit works in Fallback, but no line
cursors are shown. I've let the foundations for that by letting ViewContext 
being
passed through the view hierarchy down to the cell content view, which should
be responsible for this (to be committed soon). The ccv will ask the vc
whether there's a cursor with an offset in a given cell, and if so, where that
offset is; it'll then draw a line cursor somehow (probably by placing an extra
vob).


My request:

Tuomas, could you please factor out / rewrite the algorithm from the
ExternalEditor class? We need it for Fallback, because we cannot edit Jython 
scripts
(for the real client) in one-line cell vobs. We don't necessarily need to
use it for an actual external editor: we could just use an AWT text pane as
before (maybe in a dialog box), but to keep the span identities we'd need the
extedit algorithm again (because we only get the "before" and "after" strings
from the text pane, not the edits).

I propose the following interface:

    List respan(List old_spans, String old_text, String new_text);

i.e., the algorithm gets the old spans (as TextSpan objects), the old text
and the new text, and produces the new spans. ('respan' is the first name that
came to mind, feel free to change.) Strictly speaking, though, the second
argument is redundant, it could just be:

    List respan(List old_spans, String new_text);

That's not as symmetrical, but more robust and thus likely better.

Instead of Lists, Enfilade1D objects would be perfectly fine.

Anyway, do you think it would be a great hassle to implement this?

- Benja