On 30 January 2013 20:36, C. Scott Ananian <csc...@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. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel