On Aug 31, 2007, at 8:00 , Eben Eliason wrote:
The implicit saving on activity close gets in the way of how etoys traditionally worked. If I create, say, a simulation, I will arrange everything and then save that project, so when I later open it for demonstration, it is in a state ready to be started. But when I then run the simulation and quit, it will not be in the ready-to-run state anymore.
Any idea how that problem should be tackled in Sugar?
Hmmm, that's a little tricky. The implicit saving is designed to track versions naturally and to prevent data loss, but it does seem to get in the way in this case. I don't know the APIs myself, but I assume the activity gets prompted to save upon close and then handles the save itself. It seems you could keep track of "read" vs "write" actions, where pressing "run" or "reset" buttons (basically a revert button) wouldn't count as "write" modifications. You would only need to save upon close if code or graphics were actually changed during the session.
Well, in Etoys there really is no distinction between "authoring" and "running". Like, we can't really distinguish between a kid moving an object intentionally to a new "start state" or moving it while playing a game.
In any case, you might actually think of this to your advantage. Since the files are (will be) properly versioned, this implicit save hasn't actually erased your default simulation setup, which will still live in the Journal as an entry from yesterday when you set it all up. Instead, you now have that "starting state" entry and one or more "experiment" entries which represent the results of running that simulation. With randomness this could actually create a series of interesting results that would be useful for learning.
Honestly, I don't think we should treat every design bug as a feature.
But anyway, since in trial-3 there is no versioning, what's the short- term solution? Do we have the option to store a new version without clobbering an older one?
- Bert -