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?
- Bert -
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.
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.
- Eben
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 -
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
On Aug 31, 2007, at 12:54 , Eben Eliason wrote:
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.
How does it do this? Supposedly it just creates a new entry in the datastore, which then would have a new object id. How would it inform Sugar that the running activity instance now is associated with that new object id? If I'm not mistaken then currently Sugar assumes the object id currently "bound" to an activity instance never changes.
- Bert -
On 8/31/07, Bert Freudenberg bert@freudenbergs.de wrote:
On Aug 31, 2007, at 12:54 , Eben Eliason wrote:
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.
How does it do this? Supposedly it just creates a new entry in the datastore, which then would have a new object id. How would it inform Sugar that the running activity instance now is associated with that new object id? If I'm not mistaken then currently Sugar assumes the object id currently "bound" to an activity instance never changes.
Indeed. As we only recently realized we wouldn't land versions in time, we're just determining the details of this new approach. Right now, it has been implemented in the simplest fashion, creating a copy but dropping the activity ID and therefore its direct association. The two objects are separate.
We're experimenting to see if we can implement pseudo-versioning, so that they both retain the same activity ID but get a unique version identifier. If done properly, we might be able to properly migrate all of these files into the true versioning system later when it makes it into builds.
More directly to your question, though (after re-reading it I see your original point), I don't think we have to switch the associated ID. Each copy is identical at that point, so it doesn't really matter which one is the one that is continued forward. They will appear ordered in the Journal by the time at which they were saved, so when the first copy...the one you originally opened, finally gets saved and closed, it will appear as the most recent one.
- Eben
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eben Eliason