Old Develop activity

The Develop Activity is the "Activity for making Activities" in Sugar. In the spirit of Constructivism, OLPC needs a collaborative, intuitive and simple mechanism for fledgling hackers to write software in the same class the officially supplied activities. It needs to be accessible for both educators who need implement a solid early computer science curriculum and young people who simply wish to play with their computer to make things for making's sake.

Early screenshot of Develop

Purpose and Goals

Minimalistic and Intuitive Interface for Writing Activities

Develop needs to abstract away many of the logistical complexities of software development, including collaboration and version control. It needs to Just Work. If we expect the young people to manage their source control systems and bug trackers, they simply won't (this is actually true of most people; unless it is given to them on a silver platter they will simply not bother until it is too late). As the people writing this system, we can impart a little project management wisdom in Turing-complete form. ;)

Project Management

It is important to note that develop-activity makes a significant departure from traditional IDE design; it will consider a "project" to be little more than a directory. It does not persist any sort of "Project" meta-data between sessions beyond what is stored in the .info file mandated for Activity Bundles, and the .bzr (or .git) directory of the Bazaar (or GIT) version control system. Develop may, however, persist activity-specific settings in Develop's own configuration directory. It would be best to avoid this as much as possible.

Develop will provide a means for viewing and editing Python packages other than Sugar activities. If Develop does not detect activity metadata on a reopened project, it will simply not provide Sugar specific features. The same goes for version control; if a reopened directory does not contain a bazaar branch (".bzr") or a GIT database, the version control and some collaboration features will not be available either.

Where activities currently under development will be stored has not yet been decided (journal integration?). See the Version Control section for more info.

Version Control

This is a very important component, as this will provide the basis for collaborative work as well as Journaling. We should try to implement this in the spirit of the Journal (and as tightly integrated with the Journal as physically possible).

Most version control actions should be as abstracted away from the user as possible. Develop should take care of all routine aspects of source control; newly created files shall be automatically added, deleted ones removed, etc.

The only VCS features that will be directly exposed to the user will be:

• Commit ("Write a journal entry" or similar language might be appropriate)

• A history viewer ("View Journal")

• The collaboration features. How this will work is as yet unclear as it will require a lot of sugar infrastructure.

Version control will be implemented by Bazaar.

Choice of VCS system

I originally considered git, thanks to its speed and simplicity, but unfortunately the only way to talk to it involves lots of fork/exec'ing, which isn't particular fast or well integrated. Bazaar is implemented in Python, and as such Develop can interact with almost all aspects of it.

Now I am considering git again, because all of the OLPC projects (including Develop itself) are tracked by git and git appears to be faster and lighter on memory that bzr. Suddenly forking and exec'ing doesn't seem so bad. --Orospakr 17:40, 18 January 2007 (EST)

Collaboration

Collaboration is of paramount importance, especially when people are working on things that can be as large and complex as computer programs.

A laptop could expose the bazaar/GIT branches over the mesh (at the author's option, of course), even when Develop is not running. Announcement over the Presence system would permit other Develop instances on the mesh to present users with the option to checkout or create branches of their peers' activities. (perhaps this should also interact with the activity sharing feature in some way as well). The peer could then push his changes back to the user, perhaps not by using Bazaar's (GIT's) built in push function, but rather by sending the patchset via messaging. This way, the tree originator could be prompted with a message asking if they would like to accept a change from a buddy on the mesh. This basically would permit Linux kernel style distributed version control in a very kinetic way for young people, integrated and implemented with the OLPC mesh networking system.

This feature is particularly intriguing!

Bug and Task Tracker

A little bug tracker facility would not be amiss either. This too should be integrated into the collaboration features.

The View Source key

Keys

Pressing the View Source key will instruct Sugar (would this be d-bus magic because Activities are dbus services?) to invoke Develop on the currently active running activity. Develop will then create a copy for them to change as they like (a "fork", or "branch").

Activity Bundle Creation and Sharing

Develop will provide a means to allow an activity author to set sugar activity-specific metadata (most of which is persisted in the activity/activity.info file)

Develop will also provide UI for activity bundle creation (only available when the currently open project is actually a Sugar Activity, of course), and interaction with both Sugar's activity sharing features and the public repository hosted by the OLPC project. This should almost certainly interact in some way with the Version Control features.

Human Language and Culture Concerns

Unfortunately, language keywords, identifiers, docstrings and comments are almost exclusively English or based upon English terms. This means that fledgling developers are forced to learn at least some subset of English in order to read and write both code and documentation.

There are no feasible technical solutions to this problem, because attempting to maintain translations of even one aspect (such as docstrings) is a prohibitively expensive endeavour.

There is no evidence that this is unfeasable or prohibitively expensive. Given that modern IDEs do syntax colouring and that a language like Python has a small number of English keywords, it seems very feasable to provide some mapping to native language keywords for display purposes. And since this mapping requires a dictionary to do the mapping, it would seem a fairly small job to extend that mapping to built-in function, class, module and attribute names. The system can always fallback to making the English name visible if no mapping exists. In addition to built-in mappings, this IDE could read additional mappings from specially formatted comments in the source as long as the source is in UTF-8 and arguably, for the OLPC projects, it should always be in UTF-8.

This is not an insurmountable problem. And the mapping is only needed for keywords and for identifiers with fairly clear English names. For instance, it makes sense to translate 'String' which has a fairly transparent English meaning but it does not make sense to translate 'httplib' which is an obscure technical term whose meaning must be learned, even in English.

No. I didn't suggest that in the original of this document because it would break everything. Code snippets, collaboration, everything. The only way one could sort of make this work is via some hacktacular string munging. Naturally, that would earn a stack of about 50 "Considered Harmful" documents. The best way to deal with this issue is just to consider the English-esque keywords simply part of the Python language, not the English language. (actually, as I mentioned before a docstring translation matrix is an idea, but it would be very hard to maintain.) -- Andrew Clunis (Orospakr)

Get the Code (such as it is)

Although it's very early in the development cycle, you can:

git-clone git://dev.laptop.org/projects/develop-activity

to see how it looks right now.