Comments on TAKASHI'S WORKSPACE: UNDO!

Hi there,I have stumbled across your blog while se...

2005-10-20T09:36:00.000-07:00

Hi there,
I have stumbled across your blog while searching for info on squeak. I am a final year student working on my hons project which happens to be to develop etoys. Could you direct me to any website/literature that may help me on my way?? I would really appreciate it. Thanks kel

I implemented undo once in a moderately complex vi...

2005-10-03T11:40:00.000-07:00

I implemented undo once in a moderately complex virtual-human design system. (PeoplePutty)

We basically created a recordable state object for every undo-capable module, and then recorded all the state objects. The trick was making the state object both complete and small.

I was never really happy with the results, partially because of regular poor performance, but also because of the just design difficulties arising from having a complex system with several different parts and categories of undo.

So,
hats off to you for tackling this !

Thanks Howard!I looked the Brie demo at NICT with ...

2005-09-08T09:26:00.000-07:00

Thanks Howard!

I looked the Brie demo at NICT with Julian. I was impressed the idea of using TeaMessage for playback mechanism.

Actually my idea note was for etoys (finally it becomes Tweak base), current etoys has just poor ability for undoing, so we (etoys' developers) had discussed what kind of undoing mechanism is needed for etoys at Glendale last week. So I was surprised that you had already made replaying demo in Croquet. New generation of etoys needs proper way of undo/redo/playback and even network sharing, there are a lot of similar issues of Croquet.

But I am just starting now, and there are many difficult issue for me, "gesture" model is a good suggestion that certainly I need it. If we have to care about network collaboration ??????????

First of all, I'm going to study the undo model of Emacs. It has same aspects than we expected in etoys in many ways, it has infinity undoing, besides you can undo even after you executes user script written in elisp. I'd like to know how Emacs could undo smoothly unless saving vast size of state.

- Takashi

Some things to think about for Croquet:What is the...

2005-09-08T07:44:00.000-07:00

Some things to think about for Croquet:

What is the granularity of change? Is it uniform across a system, or do different applications have different granularity?

Conceptually, there's a message history that can be recorded. By definition, the current state can be reproduced by starting with any committed state and then replaying the messages since then.

In general, we only care about messages from one tea party to another, where the source and destination are on different hosts. For example, messages from your avatar to the party or from my avatar to the party, are the ones that actually correspond to "external input". But even some of these message are pretty fine-grained (e.g., pointerMove:). Brie has a "gesture" model, where there is distinction between operations that a user thinks of as a single gesture.

For some applications, it may be handy for a user to specify certain points of time to be of interest. I don't like to make users think about explicitly saving their work, but in those systems that do force users to explicitly "save" or "publish", this forms a natural granularity that the user has actively dicided as the states worth noting.

In general, a message or gesture is not reversable: not every action has an "inverse" action that will undo it. So the only general mechanism for going backwards through time (e.g., with a scroller) is to save the entire state whenever something of interest changes. (A plausible optimization is to not constantly be saving things during normal use, but wait until someone decides they need to go backwards. At that time, we can start with the most recent convenient checkpoint and replay the messages, with saves of state after each change.)

What about interactions between objects? Suppose we treat a whole tea party as a unit as described above, where for example, messages from an "outside" party are the the things defining our history for replay. Now, suppose you are replaying the history of a space. Can you be in the space? You're a different tea party! What about the messages that are sent to get the timeline slider to move? One model for this is the "3d portal" or "God's eye view". It's a model of a space, looking from outside. You could be in a place, holding a small 3d model of some place, and simultaneously sliding a timeline back and forth that controls the tea time shown by the 3d model. Then, at some point, you could decide to jump into that model and branch the timeline to create an alternative future from the point that the timeline was at when you jumped in.

But what about messages from the party controlled by the 3d model, outward to the party that you are now in? Those messages, if replayed, would effect your own past!

And what about having multiple tea parties in a scene? For example, an object in a space could be a proxy to another tea party. I think this is a generalization of the question of what happens to the avatars of folks who were in a place being replayed.