[Sugar-devel] Autosave and Keep button

[Bert Freudenberg]

On 02.09.2010, at 09:27, Tomeu Vizoso wrote:

> On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> On 01.09.2010, at 14:01, Sascha Silbe wrote:
>> 
>>> Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010:
>>> 
>>>> My first gut reaction (not having seen it yet) is that the Keep button is a real problem generally (and causes confusion and misunderstanding in Sugar). Habitually training kids to click that icon each time before exiting will, for all other activities, generate many confusing duplicate Journal entries over time and make matters even worse.
>>> 
>>> +1
>>> 
>>>> For the Etoys case, as a workaround for not knowing your clean/dirty state, I think having the regular Stop UI button that when clicked _always_ displayed some sort of "Do you want to Keep the changes to this project in the Journal?" Keep/Don't Keep dialogue.
>>> 
>>> Having the Stop button ask which version (the one in the Journal or the
>>> one currently loaded) to destroy is a bad idea, but unsolvable without
>>> version support.
>>> Please avoid the Keep terminology in this context; it's only going to
>>> confuse users even more.
>>> 
>>> Sascha
>> 
>> That's one of the reasons I did not want to overload the exit button with saving functionality. It simply exits (after confirming) without ever saving now. To avoid confusion, it does not look like a regular stop button:
>> 
>> 
>> 
>> But you can't really discuss autosaving and keeping separately. They go hand in hand. If an activity cannot autosave, it has to rely on the keep button, right? And keeping should create a new entry - that's how it is in every activity. Only autosave destructively overwrites the current entry.
>> 
>> I am warming up to Gary's suggestion though because it's the only way to avoid needless Journal entries, unless we introduce a "save/save-as" distinction.
>> 
>> Incidentally, on other platforms Etoys does versioning itself - every project saved has a version number embedded in the file name that is not visible in the UI. In the file-open dialog, all but the highest numbered versions are hidden. Now maybe if the Journal had a "hide" attribute for an entry, the Journal would look less cluttered. Also, when running out of space the hidden entries could be used to free up space. Wait, that's re-inventing the trash can ... but maybe not a bad idea after all.
> 
> The (some?) plans for versioning in the journal called for hiding the
> less relevants revisions in the main view and only displaying them in
> the detailed view.
> 
> Regards,
> 
> Tomeu

Yes, I know. However, "real" versioning seems to be far too complicated to actually get implemented and adopted. It might be too large a step.

It would be (IMHO) much simpler if updating a Journal entry would just make a "hidden" copy with the old contents and metadata first. 

This "poor man's versioning" would alleviate the destructive nature of auto-save. It *would* be possible to access "overwritten" versions if necessary.

OTOH that's tangential to the Etoys problem, which would not be solved even by a real versioning scheme. In Etoys, auto-save is rarely what the user needs. Maybe if the explicitly kept versions were preferred over the auto-saved ones ... But then it's hard to tell. 

Hmm, remind me again why resume-by-default from the home view was a good idea. I know I supported it at the time we discussed it. It works well for e.g. Terminal. But for activities like Etoys it gets in the way. How about we allow activities to disable it in activity.info?

- Bert -