[Sugar-devel] HTML activities

[Daniel Narvaez]

On 30 January 2013 20:36, C. Scott Ananian <cscott at laptop.org> wrote:
> If you wanted to be extreme about this, you'd write all your APIs in C, and
> use gobject bindings (or alternative implementations carefully written to
> export the same interfaces as gobject would use for the C API).  But I think
> Java is actually a better API-description language for the platforms likely
> to be useful for this generation of Sugar.  (Note that I've already
> implemented the Java-to-JavaScript bridge for the Android side, so you'd
> probably just write a single implementation of the APIs in Java for both
> Android-native activities and Web activities on Android.  You've got a
> number of different options for the Sugar implementation, but if you wrote
> as much as possible in JavaScript (and where necessary, C) you could reuse
> that code in a plugin for desktop browsers running in gnome, which might be
> convenient for development and some deployments.  Many interesting behaviors
> on the Sugar side are just dbus calls, and you ought to be able to trigger
> those from JavaScript.)

I spent some time looking into this today and I couldn't find an
approach I'm fully happy with.

* webkitgtk-with-webkit1 allows access to the DOM, so we could
register an handler to listen for dispatchEvent calls. Unfortunately
add_event_listener has broken introspection so it's not working from
python. But the real problem is that this approach will not be
possible with webkit2.
* In webkit2 the only way to communicate with javascript/DOM is
InjectedBundle, because of the multi process architecture.
InjectedBundle seems a bit dubious, I've seen a mail by a core hacker
dissuggesting it to the qt guys because it was designed for testing.
Now both qt and gtk are using it at least internally so things might
be changed, but it's hard to say given that it's completely
undocumented. Anyway if we wanted to take this approach, we would
basically implement an extension library which would listen to
messages from the DOM and turn them into dbus calls. Probably we could
also add javascript methods if we wanted instead of messages. It needs
to be out of process so calling pygobject directly would not be an
option.
* Both firefox and chrome extensions have good messaging mechanisms
between content and extension that we could use. We would have the
issue to turn a full browser into a chromeless sugar activity though.
* Another possible approach is what people are doing on iOS.
javascript -> native code is done by making requests to a custom
protocol, say message://datastore_save/json_encoded_arguments. native
code -> javascript uses stringByEvaluationgJavaScriptFromString.
Should be easy to code, feels a bit hacky.