Difference between revisions of "HTML5 activities"

From Sugar Labs
Jump to navigation Jump to search
 
(13 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
HTML5 activities will be run via a WebKit instance. A JavaScript framework will expose Sugar Features to HTML5 activities. Specifically, this framework will allow to use HTML controls matching the Sugar widgets look&feel and will expose common and customized activity toolbars. The framework will also expose API for handling Telepathy (communication and collaboration between multiple Sugar machine) and Datastore (Sugar Journal reading and writing).
 
HTML5 activities will be run via a WebKit instance. A JavaScript framework will expose Sugar Features to HTML5 activities. Specifically, this framework will allow to use HTML controls matching the Sugar widgets look&feel and will expose common and customized activity toolbars. The framework will also expose API for handling Telepathy (communication and collaboration between multiple Sugar machine) and Datastore (Sugar Journal reading and writing).
  
The following schema sum up HTML5 activities architecture.
+
The following schema sum up HTML5 activities functional architecture.
  
 
[[File:SugarWebApp Architecture.svg|400px|center]]
 
[[File:SugarWebApp Architecture.svg|400px|center]]
Line 20: Line 20:
 
= Current works =
 
= Current works =
 
HTML5 activities has been choose [http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-04-22T14:04:27] as a feature for Sugar 0.100.
 
HTML5 activities has been choose [http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-04-22T14:04:27] as a feature for Sugar 0.100.
HTML5 activities will be build on WebKit2 but if time permits we will implement compatibility with previous releases running WebKit1
+
HTML5 activities will be build on WebKit2 but if time permits we will implement compatibility with previous releases running WebKit1.
 +
HTML5 activities is accepted a project for [[Summer of Code/2013]].
  
== IPC Communication ==
+
A technical architecture is described [http://developer.sugarlabs.org/web-architecture.md.html here].
Historic implementation (Wikipedia and Foodchain) use hacky ways to handle communication between Sugar and JavaScript. We need a more performance way to communicate (send API call and data).
+
The procedure to create a web activity using from a common template is described [http://shell.sugarlabs.org/~buildbot/docs/activity.md.html here].
  
Daniel explore communication using WebSocket [http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042677.html].
+
Some interesting discussion around this subject in the community:
 +
* Sugar Web Architecture [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043518.html]
 +
* Sugar Web UI [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043519.html]
 +
* Localization [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043466.html]
 +
* Renaming HTML --> Web [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043400.html]
 +
* Running HTML5 activity on other platforms [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043422.html]
 +
* How to deploy framework in the activity [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043335.html]
 +
* Datastore API [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043303.html][http://lists.sugarlabs.org/archive/sugar-devel/2013-May/thread.html]
 +
* Unit Testing [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043151.html]
 +
* Webkit1/Webkit2 compatibility [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043166.html]
  
  
== Sugar HTML Framework ==
+
= TODO List =
=== Sugar UI ===
+
See TODO list of the project on [https://github.com/sugarlabs/roadmap/issues/8].
This part of the framework should expose HTML controls matching the Sugar widgets look&feel and common and customized activity toolbars.
 
  
Manuel has done some research about components to do that [https://github.com/manuq/components-test].
 
  
=== Datastore ===
+
= GSoC Timeline progress =
This part of the framework should expose Datastore API into JavaScript. In a first step, the JavaScript Datastore API will just call the Sugar Datastore API. Some considerations about how to write a pure HTML5 Datastore are listed below.
+
* Week 1: Working sugar-build environment, create a new activity [https://github.com/surajgillespie/myactivity]
 
+
* Week 2: Develop the RadioButton and CheckBox in Sugar HTML UI, sample here: [https://github.com/surajgillespie/CheckboxRadio], start a new Sugar HTML API
==== API Use case ====
+
* Week 3: Start developing the Sugar Activity Palette
* Called by an activity to Write/Read its context (most often seen use case)
+
* Week 4: Working on DataStore handling to Activity Palette, solved issue on new Sugar HTML API
* Called by Sugar or by an activity to navigate into. Query could be:
+
* Week 5: Publish a first [http://surajgillespie123.wordpress.com/2013/07/08/gsoc/ blog post] on its work, try to fix an issue regarding popup on home view
** Filtered by title, mime type, date, …
+
* Week 6: First mock-up and specification of the Markdown activity a Markdown format editor
** Ordered by one or more keys
+
* Week 7: First version of Markdown activity [http://surajgillespie.github.io/]
** Limited to some number of results (with an optional starting offset)
+
* Week 8-9-10: Object Chooser integration in the Markdown activity
==== What is a datastore object ? ====
+
* Week 11: Publish a first version of Markdown activity in [http://activities.sugarlabs.org/en/sugar/addon/4705 Sugar App Store]. Work on an issue in the DataStore JavaScript API
* A set of properties:
+
* Week 12: Solve issue in the DataStore JavaScript API, work on a new blog post
** Some comes from Sugar
+
* Week 13: Write a new version of Markdown activity, work on setting of preview metadata in webactivity
** Some are custom properties
+
* Week 14: Publish the new version of [http://activities.sugarlabs.org/en/sugar/addon/4705 Markdown activity], Final [http://surajgillespie123.wordpress.com/2013/10/02/google-summer-of-code-2013final-blog-post/ blog post]
** All properties values type are: string, text, int, number, date, binary or external (file)
 
* A filename (optional)
 
==== Proposed interface ====
 
function DataStore.create(properties, filename);  // Return object_id
 
function DataStore.get_properties(object_id);    // Return set of properties as JSON object
 
function DataStore.get_filename(object_id);      // Return filename
 
function DataStore.find(query, properties);      // Return array of object_id
 
function DataStore_created(object_id);            // Callback interface to object_id created event
 
function DataStore.addEventListener("created", DataStore_created);
 
function DataStore_Updated(object_id);            // Callback interface to object_id updated event
 
function DataStore.addEventListener("updated", DataStore_updated);
 
function DataStore_Deleted(object_id);            // Callback interface to object_id deleted event
 
function DataStore.addEventListener("deleted", DataStore_deleted);
 
 
 
function write_file(properties, filename);
 
function Activity.addEventListener("write", write_file);
 
function read_file(properties, filename);
 
function Activity.addEventListener("read", read_file);
 
 
 
==== HTML5 implementation consideration ====
 
* DataStore and Activity will be new JavaScript namespace.
 
* This interface is mostly inherited from the existing sugar.datastore.store API [http://wiki.sugarlabs.org/go/Development_Team/Almanac/sugar.datastore.datastore]. By the way it make sense to reproduce these features because basically the Sugar DataStore can't be something else than a place to store files and metadata related to files.
 
* Files handling is possible directly in JavaScript - WebKit only - using File API [http://dev.w3.org/2009/dap/file-system/pub/FileSystem/][http://dev.w3.org/2009/dap/file-system/file-writer.html]. Alternatively we could consider than file storage will be handle by the JavaScript to Sugar interface.
 
* Event registration ("addEventListener") is inspired by the DOM events model thought it's not directly connected to it.
 
* Activity events should be raised by the JavaScript to Sugar interface.
 
 
 
 
 
=== Telepathy ===
 
This part of the framework should expose Telepathy API into JavaScript.
 
 
 
TODO
 
 
 
=== Template ===
 
A template will be provide to developers to write its own activity. This template will include the Sugar HTML Framework.
 
 
 
Daniel has wrote a first template [http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042710.html].
 
 
 
== HTML Activities ==
 
HTML activties will be developed in parallel with the framework development.
 
 
 
Manuel has started to port the Clock activity using HTML5 Canvas [http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042706.html].
 
 
 
== Other services needed==
 
 
 
Implementing demo activities is good to identify what services are not available or need more work on javascript.
 
 
 
These are identified right now:
 
 
 
* gettext
 
* text to speech
 
* touch support?
 
* power management (in the clock activity, we need a way to tell the xo don't suspend)
 
 
 
= TODO List =
 
Find [[HTML5 activities/TODO]] the todo list on this task.
 

Latest revision as of 10:58, 3 October 2013

Principles

The objective of this work is to allow developers to write activities for Sugar using only HTML5 and JavaScript (no need to write Python code). HTML5 activities could be hosted on Sugar side-by-side with "standard" Python activities. Specifically HTML5 will be displayed on the Sugar Home view like any other activities. HTML5 activities could benefit from common Sugar features (Sugar UI, Datastore/journal, telepathy, ...) like any other activities. Finally there should be no visual difference from the user perspective between a Python activity and a HTML5 activity. HTML5 activities could be named "Sugar Web Activity".

HTML5 activities will be run via a WebKit instance. A JavaScript framework will expose Sugar Features to HTML5 activities. Specifically, this framework will allow to use HTML controls matching the Sugar widgets look&feel and will expose common and customized activity toolbars. The framework will also expose API for handling Telepathy (communication and collaboration between multiple Sugar machine) and Datastore (Sugar Journal reading and writing).

The following schema sum up HTML5 activities functional architecture.

SugarWebApp Architecture.svg

Because it will force independence from Gtk/Python, HTML5 activities is a first step toward Sugar on Android.


History

The very first Web Activity is Wikipedia. Wikipedia is a Python activity embedding a WebView to display HTML Wikipedia pages. Searching and browsing is available from a standard Python toolbar. Clicking on a toolbar button change the current HTML viewed page or launch an history command (previous/next). To communicate from HTML to Python, Wikipedia embed an HTTP Server. When a hyperlink is clicked in the HTML page it call the HTTP server then run Python code.

Foodchain is another attempt to write HTML5 activities. In FoodChain there is no embedded HTTP Server. Communication from Python to JavaScript use the WebKit "execute_script" command. Communication from JavaScript to Python use the WebKit "console.log" function with a hack on the WebKit "console-message". In both way of communication, all data exchange between Python and JavaScript are converted in JSON. Two others activities use the same framework: Grid paint and Abecedarium. The framework is described here.


Current works

HTML5 activities has been choose [1] as a feature for Sugar 0.100. HTML5 activities will be build on WebKit2 but if time permits we will implement compatibility with previous releases running WebKit1. HTML5 activities is accepted a project for Summer of Code/2013.

A technical architecture is described here. The procedure to create a web activity using from a common template is described here.

Some interesting discussion around this subject in the community:

  • Sugar Web Architecture [2]
  • Sugar Web UI [3]
  • Localization [4]
  • Renaming HTML --> Web [5]
  • Running HTML5 activity on other platforms [6]
  • How to deploy framework in the activity [7]
  • Datastore API [8][9]
  • Unit Testing [10]
  • Webkit1/Webkit2 compatibility [11]


TODO List

See TODO list of the project on [12].


GSoC Timeline progress

  • Week 1: Working sugar-build environment, create a new activity [13]
  • Week 2: Develop the RadioButton and CheckBox in Sugar HTML UI, sample here: [14], start a new Sugar HTML API
  • Week 3: Start developing the Sugar Activity Palette
  • Week 4: Working on DataStore handling to Activity Palette, solved issue on new Sugar HTML API
  • Week 5: Publish a first blog post on its work, try to fix an issue regarding popup on home view
  • Week 6: First mock-up and specification of the Markdown activity a Markdown format editor
  • Week 7: First version of Markdown activity [15]
  • Week 8-9-10: Object Chooser integration in the Markdown activity
  • Week 11: Publish a first version of Markdown activity in Sugar App Store. Work on an issue in the DataStore JavaScript API
  • Week 12: Solve issue in the DataStore JavaScript API, work on a new blog post
  • Week 13: Write a new version of Markdown activity, work on setting of preview metadata in webactivity
  • Week 14: Publish the new version of Markdown activity, Final blog post