Applitude interconnnectivity

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Hi all!

I've been experimenting with applitude interconnectivity a bit, and I'm
at a point where I think I cannot go any further without actually
changing the different views, which would make the whole thing hard to
reverse. So, I'd like to discuss what I've done so far and how to go on.

What I've done (it's all in CVS, so take a look) --

* A FlobSet.fetch method which "fetches" all flobs and rends from
another FlobSet, i.e. adds them to itself, and translates their
coordinates (it gets an x, a y and a d value and adds them to the x, y
and d fields of the flobs). That's how the split Nile view is composed.

* An ApplitudeMgr (applitude manager) class that does a lot of stuff
related to applitudes and is called from a number of places; it uses the
following structure:
- There's an Applitudes cell on the system list and the standard d.2 list.
- Connected on d.1 are two other cells, Dims and Applitudes.
- Under dims, on d.2, are all dimensions associated with specific applitudes.
- Under applitudes, on d.2, we have these apps.
- The first dimension associated with an applitude is connected to it on
d.1. The 2nd, 3rd etc. dimensions are NOT connected poswards on d.1. The
next dim that is connected on d.1 is the first dim belonging to the next
applitude, not this one.
- Connected to the applitude maincells on d.1 is a corner list with
currently two elements: View, and Bindings.
- View is quite dumb: currently, only one fixed view can be associated
with an applitude.
- Bindings is more intelligent. Actually, it works just like the
system-wide Bindings list; that is, it does support modes.
- From window maincells, there is a rank on d.app-binds containing the
binding cursors for the different apps. (Actually, that's the only new
dimension introduced by this scheme.) The cells on d.app-binds are
clones of the applitude maincells. If no binds cursor exists for an
applitude, a new one is created by ZZKeyBindings1, just like for the
normal bindings.
- Windows have an Applitude structparam, which accurses one of the
applitude maincells (or nothing). This app is considered the "prefered"
app for that window. If applitude bindings are checked, it are the
bindings of that "prefered" app.
- Oh, yes: applitude bindings are checked iff the view in the data
window has an "appbindings" structparam. (That's a really *stupid* way
to do it, I know.)
- When you click on a flob associated with an applitude, that applitude
is made the prefered applitude and its app binds are checked (if app
binds are checked). Flobs have a new applitude field which can hold an
applitude maincell. The field is set by the FlobSet.fetch method.
- Um, I think that's it.

* CombinedView. This view shows the views of all applitudes the accursed
cell is in, parallel. (A cell is "in" an applitude if it's connected on
one of the applitudes dimensions.) This works well.

* MultiView. This view mixes the different applitudes, first rendering
the prefered applitude's view, then iterating through the flobs placed
by that view; for each flob's cell (c field), it searches other
applitudes than the pref'ed one, and if it finds them, it renders them
and places them so that the pref'ed view's flob and the other
applitude's view's flob with the same cell are on top of each other.
This works quite well when using only the "ZigZag applitude" (that is,
standard vanishing view), and my Notemap applitude; it looks very weird
when bringing in Nile, i.e. rendering a Nile stream and VanishingView
cells under it.

Oh, my Notemap applitude: it's a module, so you need to compile these;
it's on the AllViews list, so you can just clone it to the views list.
It has two bindings, "n" and "-", n creating a new cell connected to the
current one, and - connecting all marked cells to the current one.

* A command for Nile to register itself as an applitude:
NileDemo.REGISTER .

Both MultiView and CombinedView have a common set of databindings. (They
are both in the AllViews list.) Bindings are checked in the order (- is
like previous, + is new):
- databindings
+ applitude
+ applitude DEFAULT
- ctrlbindings
- normal binds
- normal binds DEFAULT


Huh, that explanation took more time&space than I expected. So, I'll
give you my ideas about what next tomorrow; for now, I'd be greatful for
comments on this. Thanks.
- Benja