Karma is a yet-to-be-created framework for creating very simple Sugar activities using javascript and html5. It is not intended to create powerful animations, simulations, or reusable artifacts. PyGTK and pygame are much better tools for those purposes. Check out the Karma Project blog for updates.
Team
Felipe Lopez Toledo "SubZero" is creating a prototype for Karma as a Google Summer of Code project. Bryan Berry is serving as his mentor.
Project Requirements
- Create a single prototype activity which could be used as a template for sugarizing AJAX activities. The GSoC participant should not create her own activity but recreate an existing activity such as one of OLE Nepal's flash activities.
- This prototype should have the following features:
- Simple interactive animation and audio using html5 tags like <canvas> and <audio>
- An assessment section that stores results of student's progress and gives them suggestions on improvement. Assessment info should be persistent.
- Has embedded pdf or pdf like document reader for activity lesson plan and teacher notes.
- Integrates with the Journal
- Navigation and Help elements, ideally reusing widgets from popular javascript libraries like Jquery, Prototype, or Mootools
- Some element of collaboration using Telepathy (This could be really hard, depending on the state of javascript bindings to dbus)
Technical Architecture
- ToDo* need to update this
It is preferable to use a minimalist html rendering engine, javascript compiler, and filesystem access API rather than extending full-blown browser such as Mozilla.
Preferred Underlying Components:
- Webkit for html rendering engine rather than gecko
- Google Chrome's v8 javascript engine -- Note: Mozilla's tracemonkey offers comparable performance -- Note: Sorry, but TM doesn't even compare to SquirrelFish
- Google Gear's Filesystem API because it seems to have the most traction in the linux world
- Some mechanism to support dbus events
At this time, 23 March 2009, Titanium seems to offer all of the above but warrants testing. On the XO. Other options are to use regular firefox, Epiphany, or another browser. Titanium's developers have expressed enthusiasm for extending their platform to better support Sugar.
Conventions
- Source Code stored here ? somewhere on git.sugarlabs.org
- Project Documentation kept in the SugarLabs wiki
- Code naming conventions ?
- file naming conventions ?
Meetings
Project Plan
There are roughly 4 parts to this project plan: first get titanium running on the XO, second create a very simple learning activity with javascript and html5, third get that activity running on the XO in a roughly sugarized version of titanium, fourth extend the activity to take advantage of Sugar-specific features such as the Journal and Collaboration.
- Apply for the GSoC program formally
- Get a "Hello World" Titanium app running on the XO and measure its system footprint. Compare it with regular Firefox
- Select an existing E-Paath flash activity to reengineer with javascript and html5.
- The activity should have interactive animation and sound using javascript and html5
- Layout the strings in the activity so that they are compatible with pootle
- Determine possible ways to add collaboration.
- Recreate the learning activity with javascript and html5
- Get the activity to run successfully on Titanium and on firefox. Let's ignore Internet Explorer because it does not support html5
- Integrate the activity with the Journal
- Extend the activity so that it has some collaboration features
- Document the resulting code and issues encountered so that others can build on this project.
Project Risks
- Creating interactive animations with html5 and javascript is very new technology as html5 is a new standard. It could be much harder to create animations than we expect. Risk Level: High
- Javascript animations could be very slow on the XO. Risk Level: Low, we don't need very complex animations
- It could be very difficult to interface titanium with telepathy. Risk Level: High