On 8/31/07, Bert Freudenberg bert@freudenbergs.de wrote:
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.
I'd also prefer not to write off every difference from other known platforms as a bug up front. We certainly do want to handle as many cases as possible, though, and I appreciate any feedback about these potential problems. There are a lot of new ideas at play, and they might not all be correct. I just want to explore all of the implications of these issues with respect to the current system so that we make changes when we know for sure they are necessary.
With a game, for instance, I think that keeping state automatically upon exit can actually be quite useful, as it can store the state of our game so we can resume it again tomorrow. It's not always desired behavior, but it can be a good thing in many cases.
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?
The "keep" button is going to explicitly create a copy of the current state as a new entry within the Journal, so that incremental saves are supported until we have proper versions.
- Eben