[Sugar-devel] Nobody understands "Keep"

[Gary C Martin]

On 9 Jul 2009, at 11:29, Martin Dengler wrote:

> On Thu, Jul 09, 2009 at 11:22:16AM +0100, Daniel Drake wrote:
>> On Thu, 2009-07-09 at 10:45 +0100, Martin Dengler wrote:
>>> On Thu, Jul 09, 2009 at 09:52:23AM +0100, Daniel Drake wrote:
>>>> Nobody in the world seems to understand the Keep button. People  
>>>> think
>>>> it's for regular saving and you should do it before you close or  
>>>> switch
>>>> away from your activity.

+1

>>>
>>> That's not far from the truth, right?  At least in any work-losing  
>>> or
>>> surprising way...
>>
>> It's far from the truth in that it's not normally what you want to
>> do.
>
> My quoting-foo is bad, so I've caused confusion (in myself, too :)).
>
>> To save your work, simply click the Stop button or change so that
>> another activity has focus. If you click Keep, you'll end up with 2
>> copies - one from when you clicked Keep, and one from when you  
>> clicked
>> Stop (or focused on another activity).
>>
>> As far as I understand it, Keep is useful for these types of  
>> scenarios:
>> - you've done a lot of work but now it's time to refactor/ 
>> reorganize the
>> whole thing. However you want to keep a copy of the rough version you
>> have now, as "insurance" or perhaps for reference while you re-mangle
>> the work.
>> - you've made a template for something, now you want to save that
>> template (as a blank template) before starting on a version where you
>> fill in the content.
>
> This is a great explanation -- it should be in the HIG or something.

Hmmm, this still does not cover the special behaviour that Sugar now  
treats those Journal entries with. All these entries will have the  
same activity_id, Sugar shell uses this ID to know if it already has  
an Activity resumed. If an Activity with a matching activity_id is  
already instanced, resuming one of the older/newer entries will just  
switch you to the existing instance (with no change of content).  
Collaborating, with the Sugar shell treating any single entry in this  
long chain of entries as the same, is likely to cause quite some  
confusion for those involved as well...

Perhaps visually showing all 'kept' entries as one single block (not  
multiple entries), with the past ones visually  'depreciated' in some  
way (like old undo states), might help? Perhaps the keep button is  
just wrong altogether.

Maybe Sascha's GSoC version work will help us sort out the correct  
behaviour here.

Regards,
--Gary