<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">- no "New" button. The only way to make a new project is from the home<br>view. Don't think there's a controversy here, just double checking
</blockquote><div><br class="webkit-block-placeholder"></div><div>Yup. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">- samples projects can be opened up via a samples button in a projects
<br>toolbar. For now this brings up a file dialog. Eventually this will<br>bring up a collection of thumbnails. (the assumption is that samples<br>don't belong in the journal)</blockquote><div><br class="webkit-block-placeholder">
</div><div>Almost. This has been a tricky question, for sure, and I suppose we haven't quite settled on a final solution. Our hope is to make any such for of "open" more of an initialization and not a persistently available option. Along those lines, the child would have the option to select either an example or an empty project when creating a new instance, but after that choice they would have to instantiate a new object to choose another.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I'm confused about the proper use of the journal. Two issues in particular.<br><br>- when should new journal entries be created?
<br>The code now (current stable -- build 542) seems to only make a new<br>journal entry when the activity starts without loading anything. It's<br>important to be able to save a copy but that doesn't seem to work now.
<br>Should "keep" be "keep a copy"? Should a new journal entry be made when<br>an old entry is loaded? As it stands now its easy to accidentally<br>overwrite old work.</blockquote><div><br class="webkit-block-placeholder">
</div><div>Right now there isn't a proper versioning system within the Journal. In the (near?) future we will keep differential versions of every object within the Journal, so that the history isn't lost and overwriting old work just can't happen. Keep is essentially "keep a copy." To get to the heart of the question, "keep" actions should be performed at various times, such as:
</div><div><br class="webkit-block-placeholder"></div><div>- When the sharing scope changes</div><div>- When the activity exits</div><div>- When the child explicitly presses the keep button</div><div>- Before a sufficiently large deletion occurs
</div><div><br class="webkit-block-placeholder"></div><div>The first three of these are fixed rules, but the latter is an example of an activity specified keep, and it will be up to activities to decide when this is appropriate to do. For instance, a video editing activity might perform a keep just before performing a long and CPU intensive rendering operation.
</div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">- balancing saving too often with saving not enough<br>Save gets automatically called quite often. Given that there is no
<br>"revert" mechanism it can be hard to get back to a previous state. Undo<br>is possible but that doesn't really address the case of changes<br>inadvertently being saved on exit.</blockquote><div><br class="webkit-block-placeholder">
</div><div>This should also be taken care of with versioning. Additionally, we'd like to add support for a "temporary keep" of sorts, that will prevent the number of versions kept from getting out of control. Considering the rendering example above, the most likely reason to perform the keep is to make sure the state is saved before a potential crash. Once the render completes, a few more minor changes a made, and a new render starts, there's no reason to save another version. (Of course, if it's differential, this wouldn't be a space issue as much; instead it's a concern about flooding the Journal with too many entries to be useful.) A temporary keep would push off a version to the Journal which it would hold in limbo, in case a) the activity told it to commit the version or b) the activity crashed. Future temporary keeps would simply overwrite the one the Journal had presently.
</div></div><br><div>Ben and Tomeu, please give me thoughts on this last bit. It's been implied in the HIG and was talked about months ago, but we haven't talked about it in implementation terms or API at all, yet.
</div><div><br class="webkit-block-placeholder"></div><div>- Eben</div>