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

[James Simmons]

I don't think it's necessary to split all of Sugar into multiple apps.
 I do think, however that the Journal view is an Activity in all but
name and could continue to be that without hurting anything.  The
mechanism for making the Journal a "bolt on file manager" doesn't need
to be that friendly.  What I had in mind was a config file that you
need root access to modify.  If the modifications are done incorrectly
or the alternate Activity does not load Sugar could display a message
box and then load the original Journal Activity.

As for making documentation harder, I don't agree.  Saying that Sugar
would be impossible to document without the normal Journal Activity is
like saying nobody could ever figure out Windows if you were allowed
to remove Internet Explorer and install Netscape Navigator.

We say that we'd like older children to be able to study and modify
Sugar.  Allowing them to replace the Journal Activity with one they
created themselves would be a safe way to do that.  If they screw up
the original Activity is still there.  If they succeed they can
impress their friends by customizing an important part of Sugar.

There is much in the current Sugar Activity that is not obvious.
First, it is not apparent that you can copy files from a removable
device to the Journal by drag and drop.  Second, the Views of
removable devices are designed to look like the Journal View, which
causes confusion because removable drives are nothing like the
Journal.  The Journal would need a LOT of love to overcome these
problems.  It isn't something you could introduce in small increments.

James Simmons


> 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
>
>