Implementing ZigZag (Re: Query: Technicaldescription for keybinding actions?)

[Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>]

Hi Jan,
There was actually some more I wanted to comment on, included here. But 
don't get afraid of the amount of information and design issues, as you 
can get far without taking every thread into account. As you probably 
know, things like ZigZag are really connected to everything, and we 
all have to concentrate on something - preferably not the same things :-)

On Fri, 15 Feb 2002, Jan Theodore Galkowski wrote:
> At 06:01 PM Friday 02/15/2002, B. Fallenstein wrote:
> >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.

Which is not to say that lists and tables and trees wouldn't be well 
visualized in ZZ ;-) For a reference, if Jan hasn't seen this yet, I'd 
like to point you to a couple of views that essentially visualize 
hierarchies:
http://www.iki.fi/asko.soukka/temp/zigzag/

By the way, these views will be included in the GZigZag 0.6.2 release 
(happening right now I think!).

> BUT, IMO, a structure that's a list or table or tree some day and
> in some way might WANT to be visualized as something other than
> a list or table or tree.  Without ZZ one forecloses that possibility,
> sometimes intellectually, by limiting the views of the people
> seeing the data, sometimes pragmatically, by making the resources
> needed to do something other than a list or table or tree too big
> to be feasible.  With ZZ the possibility is not lost.

But what's unique, really? I'd say the MVP model you referred to would 
always allow this, no? Maybe the point in ZigZag is that having one model 
is not having models: you can use any view to look into any data, and 
underneath, you can connect any data to anything else, which is not 
possible in case of several models.

> Agree on the former interconnection.  An issue for the Community
> down the road, 'though, is whether all interconnections are equally
> valuable and, so, should be displayed by default.  This is more
> complicated than public versus private interconnections:  There's
> no reason why interconnections shouldn't be qualified in indefinitely
> subtle shades of gray.

I'd take the position that whenever the user makes a connection, it must 
be important enough to be shown. Generated connections are another matter. 
There are several features already which help stop cluttering: usually you 
don't view but a few dimensions at a time, and you can have most two 
connections on a cell along any given dimension. The latter ensures the 
space is always "sparse" with respect to a limited set of dimensions.

I'm not saying weighting connections is a bad idea, not at all! But I'd
say it's not important with respect to ZigZag paradigm. As a sidenote, I'm
sure it's important to have every object in the system be first-class.  
Tuomas has a specification for handling connections as first-class objects
(in ZigZag, that is cells :-) which enables weighting no problem.

> I don't know about Floating World.  I really don't know much
> about Xanadu.  But I believe I understand ZZ and it is very
> important.

Maybe you'll find time to read Ted's homepage some time. Or his books, if 
only you can get your hands on some. 

> MVP is an improvement upon MVC made by Taligent for C++ originally.
> It's a cornerstone of the Smalltalk dialect I'm fond of,
> namely, Dolphin Smalltalk.  The change is subtle in many ways,
> but basically the Model component is the same, but Views know
> about Presenters and Models, and Presenters about Models
> and Views.  The Presenter is key.  This does not sound like
> an improvement, but it is.  The problem is that, in MVC,
> interaction with a user is cleaved between incoming requests
> and screen updates, and that cleave is not natural.
> 
> http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm

Thanks, this was a good introduction. Maybe it's not of that much use for 
us directly, but it's always good to know the alternatives. Maybe the 
problem really is that we have only one Model, whereas these models 
presume several Models. Plus our user interface in general is so different 
from PUIs (Parc User Interface; boxes and icons) and we don't actually 
want OOP but something like ZZ Objects Paradigm, where objects are open 
and can interleave one another.

So what we do at the moment is to have ZigZag Space as the Model.  An 
update loop generates a VobScene around a view cursor from the Model for 
every window whenever something changes. A VobScene can be directly 
rendered into a bitmap, but it understands identities so we can animate 
between consequent scenes and ask it about the object whenever a mouse 
click arrives. So VobScene is pretty much the V of the triplet.

User actions (key press like "Ctrl-Left" or mouse action like 
Click1-somecell) are passed to a Clasm function (a cellural language) 
which modifies the structure as it sees fit. This is something like the 
Presenter, don't you think? Just that it doesn't really know about the 
VobScene, it reads the mode and all from the structure.

> For example--and I apologize again for being long-winded here--a
> quick design of a ZZ Model to me would involve several different
> classes.  There'd be a ZZCell, of course, having an ZZIdentity
> and contents.  There'd be a ZZDimension, which would be, to me,
> a subclass of Dictionary.  The identity of ZZCells would be the
> key to the ZZDimension, and each Association in the Dictionary
> would have as its value a subclass of Pair, perhaps named
> ZZCellLinkage (not happy with that), with a PosWard and NegWard
> component, each being a ZZIdentity.  Now, ZZIdentity would be
> completely internal, not being something a user would ever see.
> If there were to be a default identity for a cell, it would be
> carried in the ZZCell object as well.  I'd create a ZZCellNames
> class, a subclass of IdentityDictionary, which had in it a
> ZZIdentity and a ZZExternalName, the latter being a sublcass
> of Object.

This looks very similar to what we've had. We have the cell identity as a
String though, because what good is something else? The semantics can
matter, yes, like having it interpreted as an URI, or a Mediaserver
Globally Unique ID as it's in GZigZag at the moment. I'd say you'll want
to think about IDs a lot, because that's a very powerful and complex
matter.

> This design is really off the top of my head, so I apologize
> for its weaknesses.  I try to apply some of the ideas from
> relational database design when I do these classes.

I'm looking forward to hearing what kind of results you find after
thinking about this and maybe looking how the design has evolved in other
implementations (take GZigZag Java/ (0.6) and the new src/ (to become 0.8)  
implementations for example).

> > > 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.
> 
> I have no standing here.  Personally, I think it's too important
> to be left implementation dependent.

I think here we have to make the difference between ZigZag and ZigZag
implementations. Release management isn't a ZigZag specific issue, it
depends more on the implementing organization. But right, for overall
ZigZag concept we need to build a system which works building on top of 
the current implementations and in Ted's control and which allows as much 
co-operation between the implementations as is possible. 

> > > 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.

Me too. ZigZag dimensions are simply one normalization of a relational 
database, right? And knowledge management concepts like Conceptual 
Graphs and Topic Maps have that something in common with ZigZag, just 
expressed in a different way.

> >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.
> 
> I didn't say that.  I said they then needed to bundle their
> change into a skin or, obviously, an amendment to an existing
> skin.

Maybe you'd say the modes we have in GZigZag are like skins. They are 
groups of key bindings. The point in user configuration is that it should 
be simple, isn't it? A great idea you see in some conventional programs is 
that you can edit menus the same way you access them (eg. hover over an 
item an press a key, and a shortcut is assigned). That is really needed, 
otherwise little configuration will happen. The same with skins: if you 
have to work a lot to change a little thing, you just won't do it. 

> I agree that dimensions should be anything users want them to
> be.  I do not agree that key bindings should start out undefined.
> I agree that key bindings should be changeable.  I don't agree
> that a lot of effort should be devoted to building a macro
> system for making key bindings.

Actually, we're not talking about "a macro system" but a scripting 
language. A complete programming language and environment that can be used 
inside ZigZag, will also be used to define key bindings. In its simplest 
form a binding will simply be a call of a predefined function - but it can 
be anything the user's programming skills allow. 


I know scripting is a delicate issue, but I'm completely for it. And not 
with some crappy macro system but with a real programming language. At 
least we developers are programmers and can appreciate the power. And Ted 
has been saying how programming is something everybody should know at 
least a little, just that programming must be made easier for this to be 
achieved. Maybe you mean we could go with some existing language instead 
of making some of our own? That's a good question, and we've made 
a decision to this direction for GZigZag. I think you could well use 
Smalltalk.


Excuse me my inelegant language. I appreciate the conversation,
Tuukka

-- 
-- Trying to catch me? Just follow up my Electric Fingerprints
-- To help you: Tuukka.Hastrup@xxxxxx
                http://www.iki.fi/Tuukka.Hastrup/
                IRCNet: Stugge@#pii,#gzigzag,#ynna
                ICQ #11321669