Just a clarification:

Playground is saving after each change, not only after a Go. To some extent, it is some sort of duplication with the DoIt actions, but the Playground saves the entire code, not just the executed one.

It saves the contents in a play-cache folder by default, but you can configure it to be in a central folder shared by multiple images.

The idea is exactly to try to find a mechanism that is transparent and let's you play without worrying about save/load. We still have to refine the mechanism a bit though.

Please also note that GTSpotter searches through past Playground pages which means that discovery is now easier than before.

Cheers,

Doru

On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:

> On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier@gmail.com> wrote:
>
>
>
> 2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
>
>
> ===
>
> We need something very low friction, like automatic saving/remembering.
>
>
> Why not searching among the doit(s) stored in the changes?
>
> Thierry

Yes, that combined with Workspace's 'Previous contents' and the new automatic saving of Playground after Go.

Isn't the Playground saving after go a duplication of the Changes recording of the associated doit?
��

It just needs to become a really safe and dependable - so that you just know you can safely close a workspace/playground with an important script and always can get it back.

I rebuilt my images regularly, so it could be nice to have that linked to a repository. And yes, simple and dependable. Like in: there is no need to explain how it works... Or that the how is obvious.

Saving states of the workspaces / playground in a kind of log and doits as actions on those? Visible in searches? Stored in the package cache? Robust to multiple images use on it?

Thierry

www.tudorgirba.com

"Every thing has its own flow"