[Sugar-devel] [DESIGN] Re: PR comments on 'Save as'

[Tony Anderson]

Hi Sebastian

If you think the design is bad, you have had several weeks to bring this 
to our attention. Even now, I would appreciate some insight into your 
concerns.

Your assertion that 'This is likely not possible because activities may 
be saving state at any time (supposedly it happens on every "change of 
view") so really "not saving" would be at best ignoring few seconds of 
work and at worst, losing a day's worth.'

has been answered repeatedly. The problem is that the activity is saving 
against the jobject_handle given by the resume. This means these changes 
change the original so that the user can not go back. This is contrary 
to the expectations of users and is really a flaw in the design 
presumably introduced when the 'keep' button was removed. The solution 
which Utkarsh has implemented is to clone the jobject when the activity 
is launched. This way these changes are made to a new object.

When the user quits, if the user changes the name of the project, it is 
saved as the new jobject under the new name. No action is taken re the 
original.
If the user does not change the name, the new jobject is saved and the 
original is deleted as at present. You have repeatedly said that there 
was a risk of work being lost. This is only if the user chooses not to 
keep it. Since the user can erase a Journal entry at her discretion, the 
only risk of loss is by a system action.
If that happens, it will not be a consequence of the design.



On 07/11/2016 02:40 PM, Sebastian Silva wrote:
>
> Hi Tony,
>
> We have been discussing the design of this feature since a thread in 
> early June [1].
>
> Since then, Utkarsh has worked on the "jsfiddler" [2] which is not 
> what was proposed in the "Sugar on the Ground" proposal.
>
> [1] 
> https://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg41998.html
>
> As part of Sugar-on-The-Ground GSoC project, Tony has proposed to
> reenable the automatic save-as dialog that some found annoying when
> exiting activities.
> The proposal is to add a 'don't save' option as a strategy to avoid
> journal clutter.
>
> I would like to ask for input from the community on this topic.
>
> Also if somebody could point Utkarsh to the Sugar version where this was
> removed so that he may find the code and start from there. After some
> digging, I could not find it either in changelogs or in git history. If
> I remember correctly this was removed in Dextrose first.
>
> I am eager to help Utkarsh complete his proposed features. That's why 
> I tried his patch and gave feedback where I thought it was appropriate.
>
> I understand your need to test on fedora 18 (currently you use Sugar 
> 0.106, if I understood correctly).
>
> Perhaps there are rpm files for Sugar 0.109.1 which was just released, 
> that could serve as a good base.
>
>
> [2] jsfiddler patch 
> http://lists.sugarlabs.org/archive/sugar-devel/2016-April/052346.html
>
> El 11/07/16 a las 03:23, Tony Anderson escribió:
>> Hi, Utkarsh
>>
>> I must apologize for trashing your PR. It takes a lot to get me 
>> angry, but yesterday I was.
>  <...>
>
> Going back to Design:
>>
>> To me the essence of this feature is two-fold:
>>
>> 1. To require users to supply a title-supplied-by-user.
> I suggested that the initial text for the entry be as it is now "xxx 
> Activity" instead of blank. You are proposing changing it to "Untitled".
>>
>> 2. To enable users to resume an activity, make some changes and then 
>> decide to make the result a new instance - preserving the original. 
>> This is why
>> the feature is called 'save as', because that is how user's do this 
>> in most document-handling applications. Currently, this is not 
>> possible in Sugar.
> This is likely not possible because activities may be saving state at 
> any time (supposedly it happens on every "change of view") so really 
> "not saving" would be at best ignoring few seconds of work and at 
> worst, losing a day's worth.
>>
>> I don't know if it is possible, but I would suggest withdrawing this 
>> PR and creating a new one - same code, of course. Then I think there 
>> needs to be a gif animation and explanation of the feature. At that 
>> point, comments would be welcome.
> The PR is perfectly overwritable with the command `git push --force`. 
> That said, I had only asked for a branch in his git fork, but a PR is 
> perfect.
>>
>> My understanding of this is the PR is the developer's presentation of 
>> the result of their work to be reviewed for merging into the master. 
>> It is not a design forum. 
> It could well be, as it is quite accessible. We seem to be having a 
> design discussion 
> <https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/327>. Animations 
> are welcome any time of course. In the meantime nothing beats testing 
> the patch.
>> Before work is done on creating the code represented by the PR, the 
>> design should be done. No developer can code without knowing the 
>> intended outcome. Naturally, comments on the PR may result in changes 
>> to the code but changes made from a working base.
> This was my concern since June. I have only read what I consider very 
> poor requirements and perhaps that is why, having tested it, I still 
> don't understand the intent of the implementation.
>>
>> In the end, the developer's may indeed reject this and other PRs and 
>> thus prevent many Sugar users from benefiting from them. That would 
>> be sad. However, it is open source and it certainly can and will use 
>> be used in deployments. This, of course, is one of the great freedoms 
>> in free software.
> I can only agree in underlining the importance of freedom.
>
> Have a great week.
>>
>> Tony
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20160711/b10c5a06/attachment.html>