[Sugar-devel] Browse and the move to WebKit

[Marco Pesenti Gritti]

On 21 June 2011 23:23, Daniel Drake <dsd at 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