[Sugar-devel] [Dextrose] Some quick comments on the Journal in 11.2.0 build 16 and Dextrose 508

[Gary Martin]

On 2 May 2011, at 04:59, Bernie Innocenti wrote:

> On Sat, 2011-04-30 at 17:55 -0500, James Simmons wrote:
>> On an XO-1 you probably could not copy a 700 MB video to the Journal
>> at all.  My experience with CBZ files (Comic Book page images in a Zip
>> file), which are generally 60 MB or so, made me question the wisdom of
>> having such large files in the Journal.  As a result, I made a second
>> comic book reading Activity called Read SD Comics, which is designed
>> to store the CBZ's on an SD card.  The Journal entry is merely a
>> pointer to the file on the SD card, and contains metadata like last
>> page read, etc.  This is a big improvement, in my opinion.  You can
>> get a 8 Gig Micro SD card with an SD adapter for about twenty bucks.
>> This works perfectly with an XO-1, except that Activities in general
>> don't use the SD card for anything.  The Read SD Comics approach could
>> be ideal for files that are much too large for the Journal itself,
>> like 700 MB movies.
>> 
>> You may also be familiar with my Sugar Commander Activity, which is a
>> limited function Journal Activity alternative.  It is limited in
>> function because only the original Journal Activity can do things like
>> copy files to removable drives.  If it was possible to use my Activity
>> in place of the original Journal Activity I could make it do much
>> more.  If we had a generalized method of doing this we could have
>> several possible Journal alternatives.  A child might start with the
>> basic one and change to something else when he got older, for
>> instance.  I remember in Windows 3.1 you could specify what executable
>> you wanted to run as the Program Manager or File Manager.  This let
>> you customize the OS in interesting ways.  The nice thing about having
>> a pluggable Journal Activity is that instead of patching the existing
>> Activity and getting a consensus that your patch is worthwhile you
>> could create something radically different and throw it out to succeed
>> or die on its own merits.
> 
> The Journal was indeed an activity initially. It was integrated into the
> shell some time later, to solve some UI issues I can't remember. Perhaps
> Marco could tell us more.

Pretty sure it was Tomeu who did this integration work (apologies Marco if not), and as you mention below the main engineering win was on the memory footprint and improvements in code re-use. There was no specific user facing design changes when this migration happened, though there were ongoing discussions about improving the integration of Journal into the Sugar UI by making it more of a core Sugar view.

> If it's feasible, I'd be in favor of letting kids experiment with
> various journal implementations. In Android, even the Home application
> is replaceable by users and I think we could do the same in Sugar.

I'd say for anyone trying to teach a class or provide support/maintenance/documentation this would be a nightmare. Journal is and should be a core part of the Sugar platform you can rely on being there, not a bolt on file manager, though I agree Journal needs more love (e.g. multi object select operations would be a welcome addition). Allowing Activities more control over the Data Store would seem OK but only as long as it can be engineered in a way not to increase the security/safety risks of folks data.

Regards,
--Gary

> Shredding Sugar into multiple application has a downside: each process
> needs to import all the Python modules again, which results in higher
> memory usage and slower startup. My last calculations on the XO-1 were
> in the order of 2-3 seconds and 40-60 MB per process. The worse
> offenders were PyGTK and NumPy. The latter has already been removed from
> Sugar and other core activities. The latter could, one day, be replaced
> by PyGI and GTK 3.0, which promises lower memory usage, but until now we
> have no numbers backing this claim.
> 
> -- 
> Bernie Innocenti
> Sugar Labs Infrastructure Team
> http://wiki.sugarlabs.org/go/Infrastructure_Team
> 
> 
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel