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 >> [email protected] >> http://lists.sugarlabs.org/listinfo/sugar-devel > > _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
