Expose Journal, Home, Group, Neighborhood, & Frame Sources

[FGrose]

It would be helpful to have a path to view the Journal source code.

Perhaps in its Frame panel.

This would help budding developers, testers, and others to discover and understand the system.

[FGrose]

We should be able to examine (and eventually modify) the source for all the views.

This will help in general system understanding and support the evolution of new models and uses for the underlying information.

[tomeu]

we need a design proposal

[FGrose]

Replying to tomeu:

we need a design proposal

I envision a standard 'View Source' menu item on the frame icon extended hover palette for all the top Frame icons (Neighborhood, Group, Home, Activity (arguably redundant), Journal, and open Activities) and, come to think of it, I'd like to have the same convenient access to the source code for lower Frame icons--the Speaker, Network, Storage devices, etc.

This would cater to or stimulate budding systems developers as well as help Activity developers understand the Sugar system code.

[FGrose]

As discussed in this mailing list thread,  http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg12571.html, learners like to customize.

We can guide them to learn deeper concepts by giving them ways to encode their customizations. (Providing a convenient undo, save, and restore facility for their work would accelerate their learning.)

The 'Modifying Sugar' chapter in our manual,  http://en.flossmanuals.net/Sugar/ModifyingSugar, provides a nice entry ramp for this learning activity. We could provide a similar tutorial for other Sugar features and then benefit from the creativity of all our learners.

[FGrose]

Providing the Sugar toolkit source on every 'View source' invocation can confuse the Learner by lack of context. Which scripts map to what behavior?

Providing it when requested from a particular interface object palette would provide the Learner with important context because the source responsible for the particular software object could be pre-selected or featured first in the View source display.

[walter]

Note that the Sugar Toolkit source is now accessible from the Sugar activities View Source toolbar. When doing that work, I added access to jarabe from the Journal's Frame entry ( http://lists.sugarlabs.org/archive/sugar-devel/2011-May/031511.html). That code didn't survive design review as it was a bit too much of a special case, but it would be pretty easy to do for all of the Sugar components, including View Source itself.

One thing we need to be able to do in addition is some sort of cloning as per the Activity bundles. We could modify sys.path to look in ~ for Sugar modules but if the user makes a mistake, we need a simple way to recover: perhaps something as simple as if ~/jarabe exists, then prompt the user on launch as to whether to run Sugar from ~ or /usr/lib/python/site-packages