On 21 June 2011 23:23, Daniel Drake <d...@laptop.org> wrote: > You could have been even more convincing if you had used this API: > http://webkitgtk.org/reference/index.html > (yes, its webkit1, but it looks excellent from a GTK perspective, and > a breath of fresh air after seeing what mozilla put you through with > hulahop etc!)
The reason I posted an example of the cross platform API is that I think it's what really set it apart from gtkmozembed. We would be using (directly or indirectly) the same API everyone else is using which means 1 it will be complete, 2 it will be stable, 3 it will be maintained by the core webkit developers. > So, let me see if my understanding lines up with yours. > > WebKit2 provides an API specification, and all of the different > frontends (Qt/GTK/...) implement that API, with only the minor tweaks > needed to make it fit in to the platform? Yes. > In your example, WKViewCreate() must have been provided as a > GTK-specific thing, as it returns a GtkWidget. And the other platforms > would provide their own platform-specific implementation? Yes. > If I understand it correctly, the webkitgtk developers are aiming to > provide both options. First, the cross-platform API implemented to > return a GTK+ widget (looks like they've made great progress there). > Secondly, a refresh of the GObject-style API, implemented based on top > of that cross-platform API. > > This is what seems to be suggested here: http://blog.kov.eti.br/?p=110 > Do you agree with that interpretation? That's also my understanding. > As you suggest I do plan to get closer to the upstream development to > really get a grip on this, but firstly, I'd be interested in your > opinion on 2 further points: > > 1. If my understanding above is correct, do you think Browse should go > with the cross-platform API, or the upcoming GObject-style one? I went back and forward on this. I was annoyed about introducing an extra layer (compared to direct python bindings of the cross-platform API), since there is already plenty of them in that stack. Though I think I'm now pretty convinced using the GObject API is the best approach for Sugar. It's more practical because there are people working on GObject but not direct python bindings. More flexible because you could use it from any language with gobject-introspection bindings. More consistent with the rest of the stack. > 2. In order to get Browse, Help and Wikipedia up and running on > webkit, do you see the need for a hulahop equivalent? Or some kind of > sugar-level web widget abstraction? Or just direct calls into webkit. I'm not sure. I think hulahop in principle is pretty much equivalent to WebKitGtk + PyGi. In practice though I suspect there are going to be differences on the amount of code required to write something like Wikipedia and Help. If it's too much, people will just cut/paste the whole Browse, which I think we should avoid. The way I would approach it, is to first port Browse basing it directly on WebKitGtk. Then port Help or Wikipedia and see if it make sense to share code. If it's generic enough to be upstreamed we should try to. If it's sugar specific, adding it to sugar-toolkit would probably make sense (a common toolbar implementation for example?). The hardest case are activities which implement their content view in html and the rest using native widgets. Just some thoughts: * I'm not really convinced about using the web page exclusively as a DOM tree and try to manipulate it outside the sandbox. I'm not going to elaborate much on that to not digress, suffice to say that you wouldn't be able to use stuff like the canvas with that approach. * I like the idea of activities based exclusively on the web stack, using a local nodejs server to communicate with the system, but it's a lot of work. Using the cross platform API to write the viewer would be the most sensible approach, so it doesn't really affect Browse anyway. http://marcopg.org/2011/06/12/html-activities/ * Injecting javascript is a bit of an hack but it might be a practical/low cost solution. WebKitGtk doesn't seem to have something like iOS stringByEvaluatingJavaScriptFromString but it looks like it should be easy to add. I'm not sure about browser -> application communication, maybe we could use window.postMessage and some hooks in WebKitGtk to listen to those. It could even be abstracted as sendMessage/addMessageListener kind of API, in both directions, using json messages. Marco _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel