[Sugar-devel] journal / datastore question

[Gary Martin]

On 2 Dec 2010, at 05:31, James Simmons <nicestep at gmail.com> wrote:

> Erik,
> 
> I believe that the write_file() is always to the Journal entry you
> resumed from.  You can certainly read and write to any number of other
> Journal entries, but the write_file() only writes to the resumed
> entry.  It is possible to avoid creating a Journal entry.  For
> instance, Get Internet Archive Books downloads e-books from the IA
> website and puts them in Journal entries, but it does not create its
> own Journal entry and cannot be resumed from a Journal entry.

I always missed that feature, I'd love it if it remembered my previous search history and linked to the books it had downloaded. That way it could act as a mini library, and different GIAB sessions could be used to collect together books for a given project/subject. Example, teacher asks children to search and download books about a certain topic - that GIAB journal entry would then be a very useful reference later for a child to review and carry on work.

>  There
> are a few Activities that could benefit from that approach.  For
> instance, both Terminal and Log create Journal entries that do nothing
> useful.  (resuming from one of these entries does nothing that
> starting the Activity from the ring does not do).

Terminal has very useful resume states! It remembers the previous screen buffer of text, all the tabs you had open, and where each was in the file system. Very handy to use several Terminal journal entries for different tasks. There was also some investigation into storing the command history buffer for each, but I think it's just using a shared history fir now.

> In my opinion you should stick to flows that the user expects instead
> of inventing new ones.

+1 if you are talking about the Sugar work flow... Sugar has avoided the multiple documents per application instance to keep the user experience simple, automatic storing of Journal state (so the user never has to worry about saving) is a key part of the design. Try to consider the object chooser as a UI for importing other journal objects, it is not intended as an 'open file' dialogue. 

In a few cases a tab metaphor has been used for something similar to multiple documents, but it's been contentious and does rather complicate the activity UI. The other metaphor used by Record and Browse is a strip of thumbnails across the bottom of the activity, Record is closer (I think) to the workflow you described, where image/video/audio objects are individually stored in the Journal, and the Record object state 'links' to those objects it created.

--Gary

> James Simmons
> 
> 
> On Wed, Dec 1, 2010 at 7:55 PM, Erik Blankinship <erikb at mediamods.com> wrote:
>> Let's say I have a gimp-like activity.
>> I launch the activity and it is "empty".  I open an image file via object
>> chooser, save the file back to the datastore.  I do this a few times.  When
>> I close my activity, I keep a reference to the datastore-id of the last
>> photo I edited so that it will resume with that photo.
>> When I reopen that activity-instance, I look up the last edited photo by its
>> saved datastore id and can resume work on it.  I close the activity again
>> and the datastore-id of the image is preserved.
>> Now, I go to the journal and open the gimp-line activity via an image file
>> (A.png) in the journal with a supported mime-type.
>> My activity's read_file figures out we are opening an image, and handles it
>> accordingly (it also keeps a reference to the open file).
>> The child makes some edits and saves their changes to the image.   I write
>> the changes to A.png in the datastore via the file handle I kept open.
>> In the same activity instance, I close A.png and open another image (B.png)
>> via an object chooser.  I work on that file and then quit the activity (with
>> an intention to save changes to B.png).
>> At this point, I am  prompted with a dialog box asking me to add metadata to
>> A.png  ... (i guess because that is the file used to open the activity?).
>> Is there a way to end this activity session with the final write_file being
>> to an activity instance -- not to the file used to open the instance?
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>> 
>> 
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel