[Sugar-devel] HTML activities

[Daniel Narvaez]

Hello,

the desire to be able to write activities using html has been expressed several
times by developers. We have seen several approaches but there is not much
support for it in the core platform yet.

I and Simon have been trying to figure out how to best integrate this with the
existing platform. Bits of code can be pulled from the sugar-build html branch.
We don't have much of a demo yet, but I think the basic pieces of the
infrastucture are becoming clear, so I thought it would be good to try and
summarize them in an email to the list.

1 sugar-toolkit-html

* A new module.
* Independent from the native sugar API, so that html activities might be run
  on other platforms, like Android or even inside a web browser.
* HTML equivalents of the gtk widgets. For example Toolbar and Palette.
* Per-platform (sugar-os, android, web-browser...) implementations of the
  same javascript interface to the sugar services. For example it might
  provide a datastore.save(metadata, file) method or an
  icon.get_with_colors(xo_colors)

2 sugar-http-server

* A sugar-os internal component. Other platforms might implement the
  html/javascript API without even using an http server.
* Implemented by the sugar-toolkit-html module but managed by the sugar shell.
* Serves the activity bundles content with something like
  http://localhost:8000/org.sugarlabs.HTMLDemo/index.html.
* Exposes the sugar services API with json methods like
  http://localhost:8000/org.sugarlabs.HTMLDemo/datastore/save
* Serves the toolkit files with something like
  http://localhost:8000/toolkit/datastore.js

3 sugar-html-activity

* Passing sugar-html-activity as exec in the activity.info creates a basic
  activity with a WebView, loading the index.html file from the bundle.
* This is what an hello world looks like
  http://git.sugarlabs.org/htmldemo/htmldemo/trees/master

Possible implementation steps

* Ability to run an html activity using "exec = sugar-html-activity", with
  working window.close().
* Toolbar widget using the icons API, perhaps without palettes.
* Datastore saving and loading.
* Collaboration.
* The rest of the UI widgets.

There are of course lots of open questions

* Should we be using existing js frameworks like jquery in the toolkit ot limit
  ourselves to plain javascript.
* How do we limit access to the http server. Can one activity access the files
  of another one?
* Should we have service methods go through the http server, or is there a
  clean way to talk directly to the python activity code. Which is better
  anyway.
* Should we try to ease the transition from native to html activities, allowing
  for example to use native toolbars?
* This is going to cause quite a bit of duplication, mostly at the UI
level, is it
   worth? Would it be better to insist on the native toolkit?

I think this has a lot potential because it allows to run activities pretty
much everywhere (if nothing else inside a web browser). At the same time it
allows to support services like datastore which are an essential part of
the sugar experience. Finally it gives powerful new tools to activity
developers, HTML being much more expressive than gtk.

-- 
Daniel Narvaez