<br><br><div class="gmail_quote">On Tue, Jul 14, 2009 at 6:27 PM, Gary C Martin <span dir="ltr">&lt;<a href="mailto:gary@garycmartin.com">gary@garycmartin.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 13 Jul 2009, at 05:46, Asaf Paris Mandoki wrote:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 13 Jul 2009, at 03:11, Gary C Martin wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Think we need to make a call on the stability of the new Physics Journal state format first, or at least make sure everyone knows the storage format may (or may not) be stable long term (hate to see a bunch of folks generating/posting examples for lesson plans only to have them all fail to resume in a few versions from now).<br>

</blockquote>
<br>
Are we talking about doing something like this?<br>
<br>
<a href="http://wiki.laptop.org/go/Physics_File_Format" target="_blank">http://wiki.laptop.org/go/Physics_File_Format</a><br>
(See also the discussion)<br>
<br>
I think the format described there is much too elaborate for our needs although the right thing to do is implement it at the elements level and that may require to do more than what we really need for this activity.<br>
<br>
 JSON sounds like a good option for the format. I&#39;ll look into the api we have available.<br>
</blockquote>
<br></div>
Cool, the simpler the better, my main concern would be that we should at least have control over the stored format should upstream change (unless upstream are willing to offer some guarantee of backwards compatibility in box2d if things do need to change).</blockquote>
<div><br>By looking at the elements api I see that there isn&#39;t that much more to to if I do it at the elements layer so I&#39;ll start doing it there. I&#39;ll reopen <a href="http://dev.sugarlabs.org/ticket/1034">http://dev.sugarlabs.org/ticket/1034</a> and post my ideas for the implementation there so we can comment on them.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We should also start considering adding some sort of Save/Load state so it&#39;s easier to test tweaks to a contraption.<br>
</blockquote>
<br></div>
You mean undo/redo? Save/Load is not a Sugar thing. Hmmm. Undo/redo would need to snap shot the state of the entire simulation on every user change... Could be a tough one. Of course with Journal state working, the Keep button is all about keeping a version of the current state (allowing you to &#39;stop&#39; and resume an earlier &#39;version&#39;) :-)<div class="im">
</div></blockquote><div><br>The problem I see with the Keep button is that you have to close the activity and open it again to restore the state. I&#39;m not talking about saving to a file it&#39;s more like picking a state and then returning to it. Something like an undo/redo but the snap shots are selected by the user.<br>
<br>Saludos,<br>Asaf<br></div></div>