[Sugar-devel] Browse and the move to WebKit
Daniel Drake
dsd at laptop.org
Tue Jun 21 18:23:05 EDT 2011
On 14 June 2011 23:52, Marco Pesenti Gritti <marco at marcopg.org> wrote:
> On 14 June 2011 20:58, Daniel Drake <dsd at laptop.org> wrote:
>> 1. I've only made half the argument above. Mozilla is bad, but why is
>> WebKit the solution? The key questions here are: is it embeddable?
>> Does it work well when embedded? Do the developers support it being
>> embedded?
>
> With WebKit2, this all you need to load a web page into a GtkBox
>
> WKViewRef web_view = WKViewCreate(WKContextGetSharedProcessContext(), 0);
> WKPageLoadURL(WKViewGetPage(web_view), WKURLCreateWithUTF8CString(PAGE_URL));
> gtk_box_pack_start(GTK_BOX(box), GTK_WIDGET(web_view), TRUE, TRUE, 0);
> gtk_widget_show(GTK_WIDGET(web_view));
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!)
> "WebKit2 will provide a stable C-based non-blocking API that is mostly
> platform agnostic. In order to achieve the goal of a non-blocking API,
> several techniques are used to make the API usable while still
> providing a comprehensive set of features to the embedder."
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?
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?
This is nice from a cross-platform perspective, but I do really like
what has been done with WebKit1:
http://webkitgtk.org/reference/index.html
i.e. they have provided a really nice fully GObject-style API that
lets you put a web browser in your app. For those of us who are
experienced with glib/gobject/GTK+ and do all our other work with
those technologies, this API is probably preferable to the
cross-platform one, simply because it is more familiar from the
outset.
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?
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?
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.
Thanks,
Daniel
More information about the Sugar-devel
mailing list