[Sugar-devel] HTML activities

Daniel Narvaez dwnarvaez at gmail.com
Sat Jan 26 09:27:05 EST 2013


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

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
* Exposes the sugar services API with json methods like
* Serves the toolkit files with something like

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

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
* 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

More information about the Sugar-devel mailing list