Old Develop activity

Introduction

The Develop Activity will be the "Activity for making Activities" in Sugar. In the spirit of Constructivism, OLPC needs a strong, intuitive and powerful mechanism for fledgling hackers to write software in the same class as all the other Activities. This mechanism 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.

Develop will be based primarily upon Pida, an IDE written in PyGTK that already implements much of what we require. It provides an extensible internal architecture which should permit us to readily implement the below requirements without resorting to ugly hacks.

Differences between stock Pida's behavior and the OLPC-specific behaviors listed below should be marked.

Purpose and Goals

A Minimalistic and Intuitive Interface for Writing Activities

• GUI mockup would be nice!

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 directory of the Bazaar 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"), 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

Version control will be implemented by Bazaar and most of the existing vcs infrastructure within Pida. 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).

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 branches over the mesh (at the author's option, of course), even when Develop is not running. Announcement over Avahi 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 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 user-friendly and intuitive 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

Pressing the View Source button 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 prompt the user whether to specify whether they wish to merely read the source code of the current activity, or 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.