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.

Meeting with Julian

I had meetings with some NICT's researchers and Julian for these two days. Although I still felt slightly jet lag as I just had backed from L.A. on last Sunday, I was excited by a lot of interesting topic at the meeting. I also showed a demonstration about Chibi-Robo stuff. We were talking about to create 3-D scripting system. I realized this goal will be not easy as I expected. I regret my work should be stopped for a while to do another work, but I hope I will be able to make up more generic version. Most interesting topic came in the last dinner. Julian asked to one researcher to use iChat to corroborative work. Now we have enough infrastructure to use video conference, so it is free to use such tool whenever you need. Actually Julian said he already sets up iChat in his home during the entire day, it isn't necessary to turn off, and he can be chatting to his son whenever he want even he is on other side of the world. The important point is you don't need to disturb by noisy bells to aware enyone. One can look at peer not to be busy now nor not. I imagine the world where such video conference technology becomes just a trivial technique, as if today's HTTP or SMTP protocols, the applications of VOIP will become different than today's one (Croquet?!). Early web is just a thing for static document, but now it becomes more dynamic thing. Julian seems to try such experiment with his iChat.

Implementation of TVML with Croquet

At last entry, I wrote the brief story of the Croquet project with NICT. But now, I am trying to describe more detail implementation of that project as I have a time on the airplane. In term of implementation, I could not say it was a good work. There were a lot of ad-hoc things, dirty patch, and less reusable. All the mess were from its primary goals. - Novice user can use. - Connect with P2P network more than 7 hosts. - The croquet space is regarded as if real NICT interior. Imagine these are not easy in current Croquet release as it is too early stage. For instance, the most strongest demand in here was we didn't have to show any error messages whenever a child touches anywhere, thus it needs a bunch of hooks in UI-related code. The lack of generalization was why I didn't show neither Squeak image nor source code of the project (I am ready to show you my source if you send me a mail). But I think I should contribute parts of codes for this project with some ways. Anyway, let's talk about points of the implementation. ** Describe animation as TVML script Honestly, the script that I described for the project was actually not TVML itself. Although much portion of the script was due to TVML, but I didn't TVML itself because; - Implementation of full set of TVML needs need effort. - I don't want to carry with new syntax into Smalltalk. Finally, the script I introduced looks like; - character:walk (name="Bob" x=10, y=0, z=10) (TVML notation) - Bob tvBehavior runSpec: #(walk x 10 y 0 z 10 length 1000). (Croquet notation) Basic idea is similar, but its expression is different. Croquet version is just a Smalltalk array, and it doesn't need the key "name" because the subject of the script is described as its receiver (Bob tvBavior references a TVML animation engine). Another significant thing is Croquet version stats the length of animation (by millisecond). The length of the animation was essentially platform dependence in original TVML (you can tune with magical numbers to try and error). But in Croquet, accurate timing was needed in network interaction. ** User interface For using as a direction board, I made the user interface be much simpler to eliminate walk-through motion, pop up menu, and dock menu. In stead of that, I put simpler UI. - Both right button and left button mean selecting menu. - The stand point of user does not move. - The degree of view can be moved by operation a mouse (180 width and 30 height). The main differences from regular Croquet is eliminating walk-through. In this work, User doesn't need to move the stand point. Besides, anyone can not make new objects or new windows. ** Network Network was the hardest work to do. Did you know current Croquet just supports up to 3-4 clients? I realize the fact when 3 days before of the demo, it makes my face pale with fear (I regretted I had been too late binder). The problem I met there was; - Become slow down. - A number of shared message was dropped down. - All host was down after one host was down. - Whenever one host is down, I have to restart all the host for synchronizing their states. I couldn't fix those problem in precisely right way as I had no time, but I managed the issue relatively ad-hoc way. - Each host has just atomic, limited states. - Reducing shared message (Cutting lasers, falling down, etc). - The interval of Heart beat (TeaParty>>runKeepAlive) was made longer. - Don't use TCP to avoid blocking. ** The fact we met from the "Open House" event. - It is hard to use if many user operate in same time. - The trackball has too many buttons. - Menus are too large for using in large display. - The pointer cursor is too small to see where is pointed. - It is hard to know each host is connected each other. - Out of memory happened each an hour.