Hi, Here is Mr. Anderson's suggestion on 'Save As Popup's design. It would be great to have everyone's suggestions and ideas on it.
Regards, Ütkarsh Tiwari ---------- Forwarded message ---------- From: "Tony Anderson" <tony_ander...@usa.net> Date: Jul 15, 2016 10:55 PM Subject: Re: Save As To: "Ütkarsh Tiwari" <iamutkarshtiw...@gmail.com>, "Sebastian Silva" < sebast...@fuentelibre.org> Cc: On 07/15/2016 03:49 PM, Ütkarsh Tiwari wrote: Hi, I have a little confusion about the feature which I need to clear. Here is what's in my mind. Please correct me if I am wrong. 1) If the user '*starts'* a new activity from 'home view' - On close the alert pops up - [ XXXXXXX ] 'Save' 'Quit' . Action on save - A new instance is created with the new name while the original instance remains intact with the previous name. Since the user started new, there is no original instance. You create a new instance (metadata). If the user gives you a title, you save the instance with that name. If the users clicks quit, you save the new instance (metadata) and quit (no document is saved). 2) If the user *'resumes' *activity - On close the alert pops up - [ XXXXXXX] 'Save' 'Quit' . Action on close - A new instance is created with the 'overwitten' data and a new name while the original instance with the original data remains intact ? This one has three possible actions: 1. The user clicks on save (not changing the title). You save the object (with the document). You delete the document at the original handle. This results in a 'save' - the user has the modified document in the Journal. >From your point of view, there are now two objects in the Journal, the original metadata file and the new object. 2. The user changes the title and clicks on save. You save the object as in case 1 and you leave the object with the original handle untouched. Now the Journal has two objects each with its own file. 3. The user clicks on quit. You save the metadata file and quit. The resumed document remains unchanged in the original entry. The new entry has no document file. This is more confusing because of the way Sugar works. On the one hand, the Journal is a record of documents created by the user. On the other it is a log of the user's activity with the XO. Conceptually, I would like to see the Journal show only objects which have a document with a user-supplied-title. With the 'remotejournal', that script should upload the metadata file for all objects. If an object has a document with a title supplied by user, the metadata and the document should be uploaded to the server. In the first case, the metadata file should be deleted locally (since a copy exists on the server for statistical analysis). In the Journal, one of the metadata fields is a boolean named 'keep'. It's use in Sugar was undefined until Walter used it for his Portfolio activity. When true, this item shows as a star filled in with a color. If false, the star shows the background color. The idea is that the remotejournal when it uploads a document, marks it as 'keep'. This signifies that there is a local copy of the document. If the user clears the star, the remotejournal should delete the local copy of the document. If the user clicks on a clear star, the remotejournal should download that document from the server making a local copy. This way the user can delete documents from the local datastore to save space and still be able to access it when needed for further use. So the remotejournal will eliminate the 'clutter' of the Journal. This script should run each time Browse connects to the school server keeping the Journal view compact and with only meaningful entries. It would also be easy to write a 'recovery' script which would sync the local datastore entries to those on the server leaving all 'keep' stars cleared. The user could then request that needed documents be downloaded. I hope this helps. Tony Regards, Ütkarsh Tiwari On Mon, Jul 11, 2016 at 11:14 PM, Tony Anderson <tony_ander...@usa.net> wrote: > Hi, Utkarsh > > It appears that Dave Crossland (see sugar_dev) concludes that you are > correct - the best thing in the alert is to leave the project name blank. > I am leaning this way as well. It shows that a name is needed. > > Tony > -- Regards, Ütkarsh Tiwari
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel