[sugar] [patches] TurtleArt+Journal

[Eben Eliason]

>
> - no "New" button. The only way to make a new project is from the home
> view. Don't think there's a controversy here, just double checking


Yup.

- samples projects can be opened up via a samples button in a projects
> toolbar. For now this brings up a file dialog. Eventually this will
> bring up a collection of thumbnails. (the assumption is that samples
> don't belong in the journal)


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.

I'm confused about the proper use of the journal. Two issues in particular.
>
> - when should new journal entries be created?
> The code now (current stable -- build 542) seems to only make a new
> journal entry when the activity starts without loading anything. It's
> important to be able to save a copy but that doesn't seem to work now.
> Should "keep" be "keep a copy"? Should a new journal entry be made when
> an old entry is loaded? As it stands now its easy to accidentally
> overwrite old work.


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:

- When the sharing scope changes
- When the activity exits
- When the child explicitly presses the keep button
- Before a sufficiently large deletion occurs

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.

- balancing saving too often with saving not enough
> Save gets automatically called quite often. Given that there is no
> "revert" mechanism it can be hard to get back to a previous state. Undo
> is possible but that doesn't really address the case of changes
> inadvertently being saved on exit.


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.

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.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20070827/5a330cff/attachment.htm