Old Develop activity

Early screenshot of Develop

The Develop Activity is the "Activity for making Activities" in Sugar. In the spirit of Constructivism, OLPC needs a collaborative and discoverable mechanism for fledgling hackers to easily create Activity software or modify/build on that of others.

In a contemporary geek terms, Develop is the Python "IDE" for OLPC, with several nifty mesh/Internet collaboration features.

Objectives

Kids read and write Code. Develop is the window to the code.

Develop provides a tabbed-text editor, class browser, and file tree viewer typical to most IDEs. This visual paradigm may change (and I am at least looking at ways to optimize it), as I have no great loyalty towards it.

Some Emacs-style keyboard commands may be implemented, especially considering that OLPC has the CTRL key in the correct place.

Guido Van Rossum and the Python community (thanks in no small part to Ivan's PyCon talk) are looking into improving Python's class and method reloading, which would permit Develop to take a more smalltalk-like approach. It would be able to mutate Activities resident in memory directly, with no stop-change-start cycle.

This might also pave the way for Develop to operate much more like Squeak, by breaking down and representing all the Python classes and functions within all modules in a project and displaying them as discrete boxes, and allowing the coder to change something and have it instantly reflected in the running Activity.

Activities are mutable. Develop is the mallet.

Develop is for both making new activities and improving old ones.

The View Source key is the manifestation of this ideal. Press View Source, make the activity better. Give it to your friends, or send the changes back to the activity's author.

No two-tiered system. Develop is for everybody.

Develop must provide, as much as technically feasible, the same development tools as used by the hackers who wrote the official activities, or those who have conventional computer equipment. OLPC chose to write the Sugar user experience in Python so that it would be easy to understand and malleable. Therefore, Develop can easily provide a full Activity creation environment, without any extra so-called "development" components, such as "toolchains" or "headers".

This means that the kids are on the same level as the upstream developers.

Develop is written in that spirit.

Writing code is often a community process. Through Develop the patches flow.

Develop uses a distributed source control manager to implement a persistent collaboration system. The emphasis of this component is to provide with children with a means to:

• create something entirely different as a derivative of an existing activity;

• work together on a single activity by merging each others changes together, to produce a single activity as a group ("Linux kernel"-style).

The XO is all about live collaboration. Develop can do Pair Programming.

The concept of Pair Programming lends itself well to the inherent collaboration features of OLPC as mandated by the HIG.

Develop will be using an embedded AbiWord widget to provide the text editor buffers. Since AbiWord is already implementing live collaboration for the Write activity, Develop will almost magically gain the same functionality, and in a way completely consistent with the platform. Considering that the XO will offer realtime audio chat simultaneously for all users participating in an activity, this will allow true remote Pair Programming.

This feature will be accessible via the standard Sugar Share button.

It is important to distinguish this feature -- which closely resembles the collaboration features in the other Activities -- with the distributed version control system. This facility is more intended to allow the kids to work together on a single piece in realtime, rather than in the long-term on an activity being produced by a group of people.

Develop is for rockstar OLPC hackers too.

Develop will make it easier for *everyone* to write activities, not just the kids. Even the current Develop, which is little more than a tabbed text editor with a treeview, should make hacking the XO a little more pleasant.

Develop will guide people to follow best practices.

Develop will provide a test-suite mechanism, easy bug-tracker and other features or open pathways to help encourage "Agile" style programming.

Develop is for both off-hours fun and classroom teaching.

Just like the rest of OLPC, Develop should have a curriculum guide for teachers to help them assist the students in using the tools, the APIs (which, admittedly, have a steeper learning curve for children who not not speak English), and basic idea of what it means to write a computer program.

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.

Implementation Discussion

What follows below is a vaguely structure set of notes on how we will likely implement all of the above requirements.

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.

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.

Choice of VCS system

Develop will use Bazaar as the engine to provide the distributed version control features. It has a smart server which can be bound to the OLPC communication manager relatively easily, and makes fairly efficient use of precious disk space. It is also written in Python, and therefore it may be read and modified readily by the users.

Although the official OLPC activities are currently tracked with git and not Bazaar, the foreign branch facility of Bazaar should prove sufficient to allow Develop to branch these.

Collaboration

Mockup of the Community View

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

Develop will expose the version control branch over the mesh (at the author's option, of course) for branching, even when Develop is not running. The Presence system would permit other Develop instances on the mesh to present users with the option to create branches of their peers' activities. The peer could then push her changes back to the original person she branched from. 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 within the OLPC mesh networking system.

Activity bundles will need to contain a repository pointer (a URI) in the metadata either pointing to a repository hosted on the public Internet or on the mesh. Thus, when a user presses the View Source key for an activity written by someone else, Develop will be able to branch the Activity. This offers up many possibilities, described below. This feature will need to deal with the situation of origin unavailability (either lack of Internet connectivity or unavailable buddy on the mesh) and fail gracefully.

Naturally, a different URI formatting will be required for branches either on or off the mesh. --Orospakr 22:08, 20 January 2007 (EST)

By using the origin information in the branch, Develop will be able to plot the development hierarchy of the Activity, giving the user a "bird's eye" view of most if not all of the community surrounding that activity's development (see mockup at right). This feature may also query Presence for the existence of any "sister" branches on the mesh.

We can not rely on the Activity's name being a suitable unique identifier given this kind of ecosystem. Activity bundles will need to be identifiable between different people publishing them; for instance, if someone modifies TamTam and shares the bundle on the mesh, the other laptops must be able to distinguish it from the upstream release of TamTam.

The Activity bundle should contain either an author field of some kind, or even a GUID (bleh). --Orospakr 22:08, 20 January 2007 (EST)

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"). If the branch is not available because the other person's XO is off or the Internet site is down or not accessible, Develop will need some sort of sane fallback.

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.

User Stories

These little anecdotes describe what people might do with Develop.

Story #1 (changing an existing activity)

This documents what a user would do to create their own version of an activity, either from laptop.org or someone else on the mesh.

1. Sally starts TamTam and plays with it.
2. She decides (or perhaps as part of a project in programming class) that it would be really awesome if she could make TamTam play instruments backwards (ok, I'm reaching here... ;)
3. She presses the View Source button on the XO keyboard.
4. Develop pops up (I am not sure how this bit of UI should be designed visually yet) and asks something like:

You pressed the View Source button.  Would you like to just look at the source code of TamTam, or would you
like to create your own version to change and give to others?

1. She clicks the second button.
2. She enables tree sharing so that others may branch her version off her laptop just as she branched it off the original TamTam.
3. Hack, hack hack.
4. She can then press the Run button to run her modified TamTam (Run will serve as the 'publish' function as well, because when you run an Activity and share it, others can click it in the Sugar mesh view and download it. Pretty intuitive, eh? :D )

Story #2 (creating a new activity)

This documents what a user would do to create their own activity from scratch.

1. Maurice wants to write a simple game, entitled "Super Cat Protect!"
2. He clicks the Develop icon at the bottom of the frame, and Develop asks if he would like to continue working on an existing activity, or if he would like to create a new one. He chooses the latter.
3. Develop creates the new Activity, initialises an empty version control repository, and displays a form to allow Maurice to enter the properties of his new project (Name, Description, Enable Sharing).
4. Hack, hack, hack.
5. Expose the repository for branching over the network if Maurice opted for it.

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)

ROTFL, it is indeed a hacktacular idea that would earn 50 "Considered Harmful" documents. User-defined variable and function names could collide with keywords in any of 200 to 500 different languages! That said, something like tooltips might not be insane. It'd have to not be some irritating in-your-face thing that gets in the way of typing though. Perhaps the most recent pointer/carat move to cross over a keyword could cause a 1-line help message on a status bar. Syntax coloring is out though, because you need to run in greyscale mode to get a decent amount of clearly readable text on the screen. In greyscale mode, the 6x13 fixed font should be readable for most kids. (not for YOU maybe; your eyes are old and probably getting farsighted with age) AlbertCahalan 16:33, 25 February 2007 (EST)

Once I get my XO I'll play around with visibility related issues. I have a feeling that I'll be able to keep syntax colourising, because the actual screen resolution does not change, only effective *colour* resolution. luminance resolution remains, afaik. Mary Lou Jepsen says that black text on a white background is the proper way to use the display. --Orospakr 23:22, 2 March 2007 (EST)

Well... the addressable screen pixels do not change. There is a blur being applied though, and then 2/3 of the data gets discarded. Here are your images modified in that way: (view them full-size only) Note that I'm being optimistic; the blur could fail to account for gamma. It should be pretty obvious that a greyscale version of the originals would be more readable. AlbertCahalan 12:43, 3 March 2007 (EST)

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.