Thursday, September 08, 2005

UNDO!

To tell the truth, I haven't cared about UNDO in my work at all. Although I am really interested in brand new feature and fancy demonstration of computer programming, but I never have been concerned real user's experience. Ah, but the time seems to be coming to do about UNDO.

From the stand point of developer, I'm really taking care of undo. Programmer's undo is revision control systems. I love to use Monticello to manage my private project in Squeak, and Subversion for other stuff. I couldn't do anymore unless such system. So I realize that one interesting issue here is why undo system is implemented in various way?!

In minimal scale, we can use just undo key in your editor. Each application has its own undo policy. But the undo buffer is removed when the editor is shutdown. Revision control helps the situation. Besides, sometimes we use more file oriented backup system. So far, my company did differential backup for whole PCs at office into file server (I made the script in Perl). In any case, the goals are same, we want to back some point in history of our computing activity. Are there any core concept in?

Let's talk about other angle of undo. Sometimes undo is implemented as command pattern. Look, we have already have another commands in our etoys system, a tile, so we can imagine if undo buffer is made in etoys tiles. If so, one can learn how tile script is written looking undo history. This is basically same as macro recording (actually, I have learned emacs lisp to record/read macro scripts so far). To achieve such feature, all operation including painting a form and editing a text should be recorded as commands (as HyperTalk has all commands for menu / editor operation).

If all operation is recorded into undo buffer, we can see the undo buffer is document itself. That is an interesting side-effect. Instead of saving document data, we can save a sequence of command. The benefit of it would have a power of generalization. Documents, undo, playback, etc. are formed same way of commands.

To proceed this concept, you can see two different documents as two snapshot from same revision tree. Because certainly, a document is written from empty document. We could see any document of same application derives one root. Hence, any document of Squeak space is regard as different version of one big revision tree described in commands.

I know the idea is based on too simplification. I didn't care any performance issue neither space nor time. But it is important to start where the simple enough point.

16 comments:

Howard Stearns said...

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.

tak said...

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

Joe Muka said...
This post has been removed by a blog administrator.
orion said...

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 !

Anonymous said...
This post has been removed by a blog administrator.
Anonymous said...
This post has been removed by a blog administrator.
Anonymous said...
This post has been removed by a blog administrator.
Anonymous said...
This post has been removed by a blog administrator.
WorldTrader said...
This post has been removed by a blog administrator.
Kelly said...

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

WATTO said...

Sports Pool
Play for FREE in our Office Pool,
and win FREE weekly prizes. Play
FREE now!
 http://www.officepoolgaming.com/

Anonymous said...

I this great sites referring this blog
free office pools Play for FREE in
our Office Pools,.http://www.free-officepools.com/
Great Sportbook too
Sportbook 
http://www.GoSportsBet.com   

Arenal Volcano 
www.arenalvolcano.com

sportbook said...

Great
sportbook
for any evil genius, hero, sidekick, henchman, or innocent bystander.
http://www.gosportsbet.com

Pker on line said...

casino on line
www.truepaycasino.com

casino on line said...

HOW TO IDENTIFY WHERE A DRIVER IS FROM:


* One hand on wheel, one hand on horn: CHICAGO

* One hand on wheel, one finger out window: NEW YORK

* One hand on wheel, one finger out window, cutting across all lanes of traffic: NEW JERSEY
sportsbooks

* One hand on wheel, one hand on newspaper, foot solidly on accelerator: BOSTON

* One hand on wheel, one hand on nonfat double decaf cappuccino, cradling cell phone, brick on accelerator, gun in lap: LOS ANGELES

* Both hands on wheel, eyes shut, both feet on brake, quivering in terror: Ohio, but driving in CALIFORNIA

* Both hands in air, gesturing, both feet on accelerator, head turned to talk to someone in back seat: ITALY

* One hand on 12 oz. Double shot latte, one knee on wheel, cradling cell phone, foot on brake, mind on radio game, banging head on steering wheel while stuck in traffic: SEATTLE

* One hand on wheel, one hand on hunting rifle, alternating between both feet being on the accelerator and both feet on brake, throwing McDonald's bag out the window: TEXAS

* Four-wheel drive pick-up truck, shotgun mounted in rear window, beer cans on floor, squirrel tails attached to antenna: ALABAMA
www.gotocasino.com

* Two hands gripping wheel, blue hair barely visible above windshield, driving 35 on the Interstate in the left lane with the left blinker on: FLORIDA

Diana said...

In computing, a buffer is a region of memory used to temporarily hold data while it is being moved from one place to another. Typically, the data is stored in a buffer as it is retrieved from an input device (such as a keyboard) or just before it is sent to an output device (such as a printer). However, a buffer may be used when moving data between processes within a computer. This is comparable to buffers in telecommunication. sportsbook, Buffers can be implemented in either hardware or software, but the vast majority of buffers are implemented in software. Buffers are typically used when there is a difference between the rate at which data is received and the rate at which it can be processed, or in the case that these rates are variable, for example in a printer spooler. http://www.enterbet.com