[sugar] [patches] TurtleArt+Journal

[Brian Silverman]

>     - 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.
>

Somehow this doesn't seem ideal. There are times were you want to 
quickly browse through a collection of projects. Cases include when 
you're first getting started and when you want to check out some sort of 
collection of some kind, perhaps of old work you or a friend has done. 
Of course you can do this one at a time but it feels like it would be 
better to be able to present collections.

Perhaps there needs to be a mechanism to start activities from web pages 
or some other activity with flexible presentation capabilities. Some way 
where a collection can be put together in an ordered way. Metadata in 
the journal could be a choice, but the journal activity has limited 
ability to present groups of thumbnails. (e.g. no way to have a grid of 
them)


>     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.

I have a question about versioning. Will journal searches be able to 
easily specify that they want only most recent versions? Version info is 
of a different kind of metadata than the others. Versions of the same 
thing feel like views of the same object, rather than a collection of 
objects grouped together by a query.

Also a comment about the journal. The theory sounds good but for it to 
be effective as described it has to be very very fast. The current 
performance makes the whole system feel somewhat sluggish. I know that 
these are still kind of the "early days" but this particular performance 
issue may be a crucial one given the central role of the journal.

Brian