Re: Query: Technical description for keybinding actions?

["B. Fallenstein" <b.fallenstein@xxxxxx>]

Hi Jan!

Jan Theodore Galkowski wrote:
> [Long warning on.  Flame warning on.]

Um, while I don't have problems with long posts, I'd really hate to see
flames becoming popular at zzdev. I don't think that your post counts as
flaming, though. ;-)

> Indeed, I propose having something like an SUnit standard
> set of test cases which validate that an implementation
> conforms to a predefined standard. 

Well, as our implementation is in Java, our testsuite is in JUnit.
However, I'm sure we can work something out that works for different
language bindings.

> The test cases could
> be CMed and they, in addition to prose description, could
> serve as a touchstone for what some "official" ZigZag
> should behave like.

Sorry-- what does 'CMed' mean?

> My personal view is that ZigZag is very (I mean really very)
> important, a crucial idea.  And using it and ZigZag ideas
> in the context of a spreadsheet-like tool or a PIM-like tool
> is barely scratching the surface of possibility.  (I'm thinking
> of structures with trillions of cells and using zz operations
> in place of SQL.)  

Yes. Basically, any highly interconnected data can benefit from ZigZag.
Usually, any structure that's not a list or table or tree is
particularly well visualized in ZZ.

In my opinion, the most important thing about ZigZag is that everything
can be interconnected, so humans can structure everything to their
convenience. In many ways, a good ZZ implementation can ease a
programmer's life (for example, by taking care of Undo and versioning on
the system level), but the most important benefit is that you can always
connect everything that belongs together.

(snip)

> To me, one consequence of not really knowing what we are
> doing yet is that I think the internals of any zz implementation
> needs to be done using the best of what's available of
> existing software design and technology, as limited as it is.

Yes, but the degree to which this is possible varies between ZigZag
implementations, because they have different goals. For example, Les
Carr's ZigZag on the Web (http://www.ecs.soton.ac.uk/~lac/zigzag/) uses
WWW standards heavily, for example XML, XSLT, Javascript, and HTML's
multimedia capabilities. GZigZag, on the other hand, can use much less
current software, because it tries to do many things that current
software cannot do; ultimately, we aim for an implementation of Ted's
Floating World design (see <http://xanadu.com/zigzag/fw99/>). This
includes, for example, Xanadu-style linking and transclusions, and these
are simply not possible with today's widely used software.

So we have to take care that some ZZ implementations can leverage the
power of existing software, and others can go beyond that.

> To me, this means using a Model-View-Presenter (MVP) triplet
> for each of Menu and Event windows, using the common Model,
> of course.

MVP? I know Model-View-Controller; what exactly is the difference to
Model-View-Presenter? (Or was that just a typo?)

Currently, the system GZigZag uses (and all other existing ZZ
implementations use) is to have the ZZ space as a Model, and completely
re-create the View each time the user interacts with the system. This is
probably the most simple and robust way to go about this. However, for
speed we're currently adjusting GZZ to support a Model-View system with
multiple Views, so that we only have to re-create the View when the part
of the structure changes that the View shows. (Like most modern systems,
we do not use an explicit Controller.)

[I'm capitalizing the terms here because 'view' has a different meaning
in the ZigZag context-- it's a scheme for showing a ZigZag structure on
the screen-- and the double meaning has lead us astray before.)

Do note that Ted's more advanced designs for ZigZag include an arbitrary
number of windows, not only the Control and Data window (as Menu and
Event have come to be called).

> It means keeping options open, avoiding premature
> limitations on design.  So, in a Windows context, that
> means cell contents should be Rich Text. 

This is fine as a design decision for one implementation, but it would
be far too limiting for all implementations. Most ZZ implementations use
arbitrary strings as cell contents. The GZigZag implementation actually
does not have cell contents at all "under the covers": on the screen, a
cell can contain text or an image, but internally, these are determined
by the connections of the cell, and references to Xanadu-like media. The
point here is that all of these contents are actually stored outside the
ZigZag spaces, and have permanent addresses, allowing them to be linked
and transcluded in a Xanadu-like manner.

Basically, we want the permanently addressable text to be pure content
without markup, for easy handling in transclusions etc., which puts rtf
out of the question. We want to have parallel markup: the markup is
attached to the text structurally inside the ZigZag space.

(Of course, on the common interface level, you can get and set the text
in a cell as a string.)

> Names of cells
> should, at least in the internals, be allowed to be any
> object, not merely a name or string, even if the internal
> reference to a cell is an internal key. 

Fine, though I think cell names must at least be representable as a
string, so that they can be serialized easily. Some time ago we had a
standardization discussion on zzdev; one idea (of mine) was to use URIs
to identify cells and dimensions globally. I still hold that this would
be the right way to go about it, as we want to be able to exchange data
between ZigZag systems and then the identifiers need to be permanent and
world-unique. (And it seems foolish to try to make all ZZ
implementations agree on an ad-hoc format, when there's an internet
standard for world-unique identifiers.)

> And there should
> be nothing which limits the number of cells or dimensions
> to any particular size:  That should be the limit of machine
> memory, not "This implementation accomodates a maximum of
> 65,536 dimensions."

Of course.

> I haven't looked at the GZigZag implementation, yet.  So,
> I have no idea if this is the kind of thing it does.
> I apologize if I offend anyone.  I do not mean to.  I'm
> just stating my view.

No, I'm sure you haven't offended anyone, though opinions may differ ;-)

> I also think this open source way of going about it is the
> right way. I see nothing to be gained by applying market
> pressures prematurely.

For your information: Everybody on the current GZigZag developers team
believes strongly in Free Software, though many people in the ZZ
community and on this list do not. So for us on the GZZ team, it's a
matter of principle, not just pragmatism about the current situation. :-)

Which shouldn't stop us from cooperating, of course; just so that you
understand the situation.

> I also think trying to develop a "ZigZag way of programming"
> and using it to implement ZigZag is a wrong way of going
> about this.  Such a means of programming is important to
> pursue and can be rolled in later.  But we don't know
> what we're doing and that kind of approach would compound
> risk, not control it.

Well, a cell programming language for user-level extension of ZZ is part
of the Floating World design we aim to implement, and in fact we have
already implemented a number of those. Currently development is underway
to implement the key bindings themselves in one of them. Writing GZigZag
in itself is far from being a current issue, though.

However, now this is really something implementations can easily choose
to do differently without losing any interoperability.

(snip)

> There should be a means of deciding when something gets into
> the official releases, although nothing says that if there is
> a difference in opinion a tree structured release organization
> might not serve.  Quaker consensus was used in the design of
> APL and served that well.  It might work for ZigZag.

Well, this is certainly something that each implementation needs to
decide on its own.

> In addition to being a Smalltalker and database programmer, I
> also have done knowledge engineering in support of the
> so-called data warehouses.  In that I use ATLAS.ti, one of
> several software packages available for qualitative analysis.
> (See http://www.scolari.co.uk/atlasti/atlasti.htm.)  ZigZag
> is wonderful for that world, and the need for and success of
> qualitative analysis software suggests there is at least a
> business niche for ZigZag, as unimportant as having such a
> niche is now.
> 
> Naturally, because I'm into database applications, the idea
> of using ZigZag structures there tantalizes me.

Would be nice to see you start using it for that. ;-)

(snip)

> > One thing that is especially important is to make the key bindings
> > configurable inside the ZZ space. In the end, this is more in the
> > spirit
> > of ZZ than any specific set of key bindings can ever be.
> 
> Yes, I understand that.  However, the entire matter of
> designing programmable interfaces is a perilous area,
> even if all ways are moved by a desire to be accomodating,
> flexible, and open, not just convenient for the implementer.
> It's kind of like the keyboard macro vs no keyboard macro
> issue within emacs.  Sure it has it, but there's some doubt
> recorded in the Manual about whether they are a good idea.
> Think of a typewriter with keys that are removable and
> replaceable to allow people to put them where they want
> them to be: Touch typing doesn't make sense in that world.
> Facility with a particular configuration of keys can't be
> developed if they don't stay put.

Sorry, but I can't follow your reasoning. If people can put the keys on
the typewriter where they want to put them, who says they'll put them in
a different position every day? This isn't what's happening with emacs
either, is it? You can configure them as you like, then you can develop
facility with that configuration, then if something nags you about it
you can change it.

It also seems to me that this is the best way to improve on the
interface: have different people try out different things. I don't think
there is anything to gain in interface development through *not*
allowing people to try out things.

In any case, I maintain that not allowing users to configure the key
bindings *is* going against 'the ZigZag way.' Not being locked in by
somebody else's structures, interfaces, keymaps etc.pp. is the whole
point of ZZ. It's like Ted doesn't say, "okay, I give you 20 dimensions
with predefined meanings and also 5 you can customize on your own."
You're supposed to be able to look into everything and change everything
down to the very bottom of the system.

(Still, of course, you can do this differently in your implementation if
you do not think this is the right way to go about it...)

> Is that tome back there what you wanted?  Sorry it didn't fit on
> the back of your calling card. (;-)}

Discussions are fine with me. :-)

One side note: When you start your own ZigZag implementation, remember
that ZigZag is a trademark of Ted's. You can either try to settle into
an agreement with him for using it, or you have to call your software
something else. Ted has proposed the terms 'hypergrid' and 'orthoplex'
as non-trademarked alternatives; both terms have found supporters in the
ZZ community, so it seems these are 'the' two terms now.

- Benja

P.S.: We, the GZigZag developer team, are also using the #gzigzag
channel on IRCNet. If you like, you can also join us there besides using
this list.