Changes

'''Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?'''

'''Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?'''

The project is to introduce a <b>save feature </b> inside Sugar where the user can save the current running activity instance by name of his choice when an activity is closed.

A number of real-world issues crop up in deployments of Sugar, especially where resources are limited (bandwidth, CPU speed, battery life, local storage, etc.) This project is related to making Sugar more usable under such circumstances.

This approach satisfies the needs referenced in the git task. Git is a little like a hammer looking for a nail. Using git for this function will likely double the size of the data stored in the Journal (based on normal experience using git). Unfortunately, we don't have this space on the XOs. The standard save/save as feature will give the user the ability to manage versions by using unique names.

*<b>Sugar Journal save option</b> - This feature introduces a <b>save feature </b> inside Sugar where the user can save the current running activity instance by name of his choice when an activity is closed. The key is to give the user a way to do what is needed, but not to force it.

 

The Sugar Journal should provide a 'save/save as' interface which should enable a user to choose whether to save the current document when an activity is closed. The interface should require a name change from 'current.activity' to a user supplied name. - If the document is derived from one currently saved in the Journal, the user should be allowed to save (overwrite) or save as (create new document) by giving a new name to the document. This could be accomplished by showing a alert dialog at close time requesting the user to supply a name or 'not save' the document. If the document has a user supplied name (by the standard activity toolbar icon), the dialog could request the user to save or to provide a new name to create a new document.

When a user resumes an activity, if the user quits, it should be saved by overwriting the previous Journal object (the current default).

If the user wants to ignore it, he can simply do so by selecting 'cancel' option.  

Libraries: Python bindings for Gtk+

This approach satisfies the needs referenced in the git task. Git is a little like a hammer looking for a nail. Using git for this function will likely double the size of the data stored in the Journal (based on normal experience using git). Unfortunately, we don't have this space on the XOs. The standard save/save as feature will give the user the ability to manage versions by using unique names.

Here are some mockups I designed-

Here are some mockups I designed-

<b>Same modal popup on close ː-</b>  

<b>Save alert popup on close ː-</b>  

<br>

<br>

             http://imgur.com/p7qg61i.png<br> <br><br>  

             http://imgur.com/p7qg61i.png<br> <br><br>  

<b>Save as modal dialog ː-</b> <br>

<b>Save as alert popup ː-</b> <br>

             http://imgur.com/RxZpbxx.png<br><br>

             http://imgur.com/RxZpbxx.png<br><br>

<br>

<br>

             http://imgur.com/n0GFgRj.png<br><br>

             http://imgur.com/n0GFgRj.png<br><br>

<br>

<br>