[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: Query: Technical description for keybinding actions?
- To: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: Query: Technical description for keybinding actions?
- From: Jan Theodore Galkowski <jtgalkowski@xxxxxxxxxxxx>
- Date: Fri, 15 Feb 2002 20:08:41 -0500
- Cc: Jan Theodore Galkowski <CodingWizard@xxxxxxxxxxxxxx>, zzdev@xxxxxxxxxx
- In-reply-to: <3C6D9364.67713CB6@xxxxxx>
- References: <188.8.131.52.2.20020215160358.00a2f1d0@xxxxxxxxxxxxxxxxxxxxxx>
At 06:01 PM Friday 02/15/2002, B. Fallenstein
Jan Theodore Galkowski wrote:
> 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
Ah. Astonishing symmetry there. Wonder why.
So, you agree the idea is a good one? That is, a
suite of test cases establishes conformity to a definitive
ZigZag implementation and that, therefore, can be in some sense,
an operational (but nothing else) definition of that?
Yes, that'll work.
> The test cases could
> be CMed and they, in addition to prose description, could
> serve as a touchstone for what some "official"
> should behave like.
Sorry-- what does 'CMed' mean?
Sorry: CM = "configuration management". It's a bad habit
an earlier era.
> 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
> of structures with trillions of cells and using zz operations
> in place of SQL.)
Yes. Basically, any highly interconnected data can benefit from
Usually, any structure that's not a list or table or tree is
particularly well visualized in ZZ.
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
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.
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
the system level), but the most important benefit is that you can
connect everything that belongs together.
Agree on the former interconnection. An issue for the
down the road, 'though, is whether all interconnections are equally
valuable and, so, should be displayed by default. This is
complicated than public versus private interconnections:
no reason why interconnections shouldn't be qualified in
subtle shades of gray.
I, for one, am highly skeptical of pushing paradigms beyond the
domain they can work in. My main reason is it is, unwittingly
not, one way of forcing the paradigms to fail to achieve what they
might. Many are very good and very valuable. But if you use
to beat a nail, they won't work. One thing at a time. If
can do a small thing perfectly, everything is possible.
> To me, one consequence of not really knowing what we are
> doing yet is that I think the internals of any zz
> needs to be done using the best of what's available of
> existing software design and technology, as limited as it
Yes, but the degree to which this is possible varies between ZigZag
implementations, because they have different goals. For example,
Carr's ZigZag on the Web
multimedia capabilities. GZigZag, on the other hand, can use much
current software, because it tries to do many things that current
software cannot do; ultimately, we aim for an implementation of
Floating World design (see <http://xanadu.com/zigzag/fw99/>).
includes, for example, Xanadu-style linking and transclusions, and
are simply not possible with today's widely used
And, I agree. I agree in the sense that compromising in
fundamental ways simply to avail oneself of "what's out
For one thing ZZ breaks rules that many of these other
systems assume. That doesn't automatically mean they are
useless, for ZZ or anyone else, but it does make their
contribution suspect. For another thing, we'll never know
what we can do with Xanadu-ZZ unless we push the fringes.
It simply is not likely that major improvements are going to
be had by making minor changes, as much as CEOs hate the
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
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
Model-View-Presenter? (Or was that just a
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
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.
I know that doesn't say a lot. Check out
Currently, the system
GZigZag uses (and all other existing ZZ
implementations use) is to have the ZZ space as a Model, and
re-create the View each time the user interacts with the system. This
probably the most simple and robust way to go about this. However,
speed we're currently adjusting GZZ to support a Model-View system
multiple Views, so that we only have to re-create the View when the
of the structure changes that the View shows. (Like most modern
we do not use an explicit Controller.)
Thanks. That helps a lot regarding the architecture.
As a side note, the MVP pattern tries to overcome the problems
which motivate many systems to exclude the 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
the screen-- and the double meaning has lead us astray
Yes, thanks. I dig.
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
Event have come to be called).
Yes, I wondered about that. It should be that way; at least
it feels it should be. The only problem it poses to me is
one of how to refer to all these objects, and how to do
it consistently and uniformly.
> 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
be far too limiting for all implementations. Most ZZ implementations
arbitrary strings as cell contents. The GZigZag implementation
does not have cell contents at all "under the covers": on the
cell can contain text or an image, but internally, these are
by the connections of the cell, and references to Xanadu-like media.
point here is that all of these contents are actually stored outside
ZigZag spaces, and have permanent addresses, allowing them to be
and transcluded in a Xanadu-like manner.
Oh, I don't know about all this. I'm ignorant of Xanadu
and I think that ignorance could be valuable to you and to the
entire Xanadu effort. It's so, so easy for implementors to
confuse the design layers in their implementation with those that
are more properly at the user interface. To make that mistake
is why many projects turn out so badly. Because one has
operationally and pragmatically made an assumption does not mean
that assumption _must_ be so.
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
a subclass of Dictionary. The identity of ZZCells would be
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
class, a subclass of IdentityDictionary, which had in it a
ZZIdentity and a ZZExternalName, the latter being a sublcass
With this scheme, any ZZCell object could be in any or all
ZZDimensions, even although, conceptually, it is in all of
them all the time. There would, in this scheme, be a need
for a ZZDimensionDirectory class or some such, to collect
all the dimensions together in one place.
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.
Basically, we want the
permanently addressable text to be pure content
without markup, for easy handling in transclusions etc., which puts
out of the question. We want to have parallel markup: the markup is
attached to the text structurally inside the ZigZag
(1) What's a "transclusion"?
(2) Why can't RTF text have markup attached to it? I'm sure
you have a good reason, but I just don't
(3) I want RTF because it's the gateway to arbitrary and
specialized character sets, like the Asian ones
stuff like the Elvish Runes of Middle Earth as
(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
standardization discussion on zzdev; one idea (of mine) was to use
to identify cells and dimensions globally. I still hold that this
be the right way to go about it, as we want to be able to exchange
between ZigZag systems and then the identifiers need to be permanent
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.)
Oh, I'm not saying anyone else should do this. I'm saying
is what my implementation is going to do. I agreed that
should be the same. I said nothing about the way I represent
> And there
> be nothing which limits the number of cells or dimensions
> to any particular size: That should be the limit of
> memory, not "This implementation accomodates a maximum of
> 65,536 dimensions."
> 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.
> 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
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
matter of principle, not just pragmatism about the current situation.
Which shouldn't stop us from cooperating, of course; just so that
understand the situation.
Yes, it should not. IMO, the freeware vs GPLware vs payware
shareware has gotten very tired and really is propagating itself
rather than dealing with reality. The problem is that
capitalism has a hard time dealing with complicated, technical
issues, whether software, privacy in an electronically connected
age, health, or the environment. Its problems are simply not
addressed, let alone solved, by a discussion regarding copyrights
and software. Its flaws are ones of valuation: It
because of systemic reasons, accurately assess the value of
things whose true value are only know 50 years in the future.
> 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
of the Floating World design we aim to implement, and in fact we
already implemented a number of those. Currently development is
to implement the key bindings themselves in one of them. Writing
in itself is far from being a current issue,
Good luck with that. A cell-level programming language sounds
interesting, although I won't focus on it soon, possibly not for
years. Other things are important. I would object, however,
supporting that was made part of an interface standard.
However, now this is
really something implementations can easily choose
to do differently without losing any interoperability.
> 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
> 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
to be left implementation dependent.
> 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
> several software packages available for qualitative analysis.
> (See http://www.scolari.co.uk/atlasti/atlasti.htm.)
> 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.
Great. Yes, it would.
> > One thing that is especially important is to make the key
> > configurable inside the ZZ space. In the end, this is more in
> > 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
> 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
the typewriter where they want to put them, who says they'll put them
a different position every day? This isn't what's happening with
either, is it? You can configure them as you like, then you can
facility with that configuration, then if something nags you about
you can change it.
And having different skins fails to support that how?
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
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
In any case, I
maintain that not allowing users to configure the key
bindings *is* going against 'the ZigZag way.' Not being locked in
somebody else's structures, interfaces, keymaps etc.pp. is the
point of ZZ. It's like Ted doesn't say, "okay, I give you 20
with predefined meanings and also 5 you can customize on your
You're supposed to be able to look into everything and change
down to the very bottom of the system.
There is a limit to which anyone can support arbitrary choice.
Even incredibly fantastic systems will, eventually, run into
the ramifications of their own choices. I don't see hiding
those consequences from users as doing them a service.
I agree that dimensions should be anything users want them to
be. I do not agree that key bindings should start out
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.
The set of key bindings should change, but change _slowly_.
I don't know how one engineers that. The set of key bindings
is the language we speak in, both to ZigZag and to each other.
Change it too fast and noone will understand you. I
embrace the need for allowing it to be changed. But if it
changes so much that ZigZag fails, users can't change what
they want either. I know: It's a risk, and, for most
the balance between safety and risk should be decided in
favor of risk.
(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
> the back of your calling card. (;-)}
Discussions are fine with me. :-)
One side note: When you start your own ZigZag implementation,
that ZigZag is a trademark of Ted's. You can either try to settle
an agreement with him for using it, or you have to call your
something else. Ted has proposed the terms 'hypergrid' and
as non-trademarked alternatives; both terms have found supporters in
ZZ community, so it seems these are 'the' two terms
Yes. Indeed, that was my first concern. I pursued that
using another channel. I firmly believe trademarks and
copyrights should be respected, primarily for the reason
artists want them to be. That'll be resolved before I
make anything public. That doesn't mean, however, that
I'll make anything public when it is resolved.
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
Hey, Benja, that's a great lead. Thanks. I've always
thought IRC should be used for lots of things besides RPG
(any DND players out there?), and I have this underutilized
mIRC sitting on my Desktop. I have tried, but don't dig AIM
and stuff _at_ _all_.
Ciao, all. It's always a great pleasure....