Old Develop activity

Please copy/paste "{{Translationlist | xx | origlang=en | translated={{{translated}}}}}" (where xx is ISO 639 language code for your translation) to Old Develop activity/translations

HowTo [ID# 56028]  +/-

Develop
[[Image:|center]]
Status:	unknown
Version:	unknown
Base:	unknown
Source:	unknown
l10n:	missing
Contributors
unknown

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 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 a community process.

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 other's changes, to produce a single activity as a group ("Linux kernel"-style).

The XO is all about live collaboration.

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.

Version Control 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.

Story #3 (creating a SoftPhone activity)

This is an example of an activity that a user might want to create along with how they might go about creating it. This is not about how things would get done, it's about what level of activity we are interested in allowing to occur within the develop activity. This is a minor application, something that would be relatively easy to create in a classical IDE, it's trying to ask the question "What happens during 'hack, hack, hack' for a 12 year old with a dream?"

• User wants to create an activity that allows any Sugar user to log into a SIP server (presumably outside the Sugar cloud) and use that server to initiate VoIP calls to the Plain Old Telephone System
• User creates a new activity
• User designs icons in the "draw" activity for the new activity, the various states of the connection, the server to which they are connecting, etceteras
• User creates a "form" of some sort into which the user can enter their configuration
• User connects the form to code snippets that validate the form values
• User connects the form in total to code that validates the whole configuration and stores the settings in some database or similar structure
• User provides a "form" for entering the phone number to call
• User connects the form entry to a code snippet that creates a SIP connection to the server, negotiates the SIP session, then sets up the RTP (voice) connection to the server
• We would presume that the SIP connection mechanism would be provided as a control of some sort, possibly integrated into the presence system
• The user might have to code the gstreamer chain to produce the RTP stream from microphone input, or that might be provided as a prebuilt control
• The user would likely connect images/controls to the SIP connection mechanism to display status and the like
• User creates a "phonebook" entry form, hooks it up to store records in the standard database/datastore
• User creates a "phonebook" view form, this would be a view on the datastore/database
• User creates a control that allows for searching the collection of numbers/addresses, hooks up that form to a function doing a filter of the datastore view

Here the user could publish the "outgoing call only" version of the application. And some other user could pick it up and decide to add an incoming call functionality:

• User creates an "always on" mechanism (think panel applet in a "normal" desktop)
• Has the always on mechanism do a SIP register on logon (maybe via the presence service)
• Has the always on mechanism allow for incoming telephone calls (opens a port in classical terms)

This might be an ambitious project for a 12 year old, but it's likely within their grasp (certainly there are 7 or 8 year olds who write more complex programs).

Story #4 (creating a school radio activity)

In the same vein as the VoIP Phone activity; a user would like to create an activity that allows a group of people to produce 5 minute live "announcements" or "school radio" programs, to be distributed to all of the laptops in the area (remote schooling situation). The program would want to have prompts to let people know that they were up next, up, and running out of time, as well as a mechanism to allow for reading "scripts".

• the user wants to create a single "channel" that will be handed off to multiple sources as controlled by a single person
• creates a radio controller activity
• adds view that allows for "adding" some number of "readers" as clickable icons from the presence service
• creates a "shared model" that simply has the "current reader" and the script (null by default) (I'm over-simplifying here)
• adds view for showing the script (imported from writer, possibly created using collaboration, of course)
• connects up the "reader" icons such that a first click warns the user that they are up and changes the icon (updates the "next reader" in the model) and the second click gives the user the microphone (updates the model to point to the new reader/laptop as current)
• possibly allow all readers to share the controller activity (allowing them to, for instance, deactivate their own "next up" status if they are not ready)
• creates a "service" mechanism that allows others to connect to the laptop running the controller activity in order to get the shared model (something like "share this activity", but in asymmetric mode).

Now, the user creates the second activity, the "radio receiver" activity:

• this activity is used to connect to a radio controller
• it pulls the model off the controller laptop and follows the connections as specified, using the "next up" model changes as signals to set up an RTP connection and the "up" model changes to start up the connection

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)

Eeeeeeek! --Orospakr 14:52, 3 March 2007 (EST)

BTW, you were only using 800x600. You'll get 1200x900. AlbertCahalan 17:54, 3 March 2007 (EST)

In case you didn't get your XO yet, here it is on a B2 display. AlbertCahalan 15:04, 10 March 2007 (EST)

I want to offer a little bit of personal experience here. I first learned to program when I was 7, I think. I didn't speak a word of English then, but I was quite motivated. I had a book in Dutch about BASIC, and a BASIC interpreter that spoke English. Basically what happened is that somehow, I learned just enough English to use it. It's almost like kids whose parents speak in some foreign language they both know when they don't want the kids to understand them: it's a sure-fire way of teaching your kids a foreign language. I had no idea how to pronounce things, of course, nor what they meant outside the context of BASIC. I knew what "For without next", "While without wend" and "Syntax error" meant, even though I had no idea what "without" was or even that it was a preposition. It helped that the BASIC interpreter only used a limited vocabulary of English messages, which were all documented in the book, but in general, I think that most programming jargon is sufficiently different from regular English, and the similarities sufficiently misleading, that a kid will be able to learn an amazing amount of it without actually having to learn English as a general-purpose human language. To this day, when I see a "goto" statement, I mentally pronounce it as "khoe-toe"...

Hi there. I'm a programmer based in Guatemala who came to this wiki not because of an initial interest in OLPC per se, but because I think this problem in particular is both solvable an worth solving. It took me a while to get to this page, and meanwhile I had made the page Source-code editor with transparent native-language display as a software idea - go there for my initial ideas on this. Here, I'll reply to the above discussion.

• I understand the point of the above programmer who learned BASIC before english. But if you have any hope that this will enter the curriculum, you want to make the barriers to ALL kids, not just the ones who naturally "get" programming, as low as possible. As a teacher, I can say that teaching programming in quasi-native vs. foreign-based language would be night and day. (I have only 3 years classroom experience, but I really want to emphasize this point. Please, don't use your geek introspection to imagine how most kids react, talk to actual kids, various different ones; or, at least, teachers.)

• This does not have to involve any evil hacks. The on-disk code would stay as true python (or css, or what-have-you). The on-screen and written code could have a clear two-way, extensible mapping (with conflicts escaped by some simple convention like a "en__" prefix for on-disk "english" code that conflicts with a mapped "localized" keyword). The comments, as mentioned above, are the hardest problem, but, again as mentioned above, an incomplete translation table, perhaps even one seeded by machine translation, is an option, and even without this aspect this is worth doing.

• The above discussion of coloring, while useful, is a separate point. The original point of raising coloring in this context is that it is a roughly-comparable computational task - it shows that this is at least computationally feasible, so we only have to worry about other aspects of feasibility.

Homunq 16:02, 28 July 2007 (EDT)

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.