[Sugar-devel] Browse and the move to WebKit
Luke Kenneth Casson Leighton
luke.leighton at gmail.com
Thu Feb 16 20:30:51 EST 2012
Marco Pesenti Gritti <marco <at> marcopg.org> writes:
> 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.
a word of caution: the core webkit developers do not like to receive
input from free software developers: you are entirely at their
mercy. they seek to gain complete control over the codebase.
if your code does not fit with what they have dictated it shall do,
your project is in jeapordy if you become dependent on them.
this may sound really... bizarre, but it is direct experience. i worked
extremely hard to create the webkit gobject bindings (which you have
been discussing and i see using) and mark rowe worked extremely hard to
destroy the efforts to make them available in a useful and useable
unfortunately, mark rowe's efforts succeeded, and the free software
community has lost the benefit of my experience and efforts to bring you
useful and useable gobject bindings, for which i deeply apologise.
it will be years before the damage done by mark rowe is fully
> > 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?
> > 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.
that's incorrect. i wrote the direct python bindings over a year ago:
the gobject bindings approach is fundamentally flawed and unfortunately
you will not find this out until you begin to try *significant* usage of the
the number of _actual_ projects that make significant usage of python
DOM bindings to webkit, in the world, is a total of one (1) application:
even in the microsoft world, the total number of actual projects that actually
make comprehensive (100%) use of python COM bindings to MSHTML (Trident) is
one (1) - pyjamas-desktop. i spoke to eric of the microsoft IE team about
2 years ago and he expressed surprise at what had been done, and confirmed
that never, in his entire career working with IE, had anything quite so
comprehensive as pyjamas-desktop ever been done.
bindings to the DOM that are not fully without fail absolutely cast-iron
guaranteed without one single exception absolutely and 100% identical _to_
this was where the shit hit the fan when creating the gobject bindings to
webkit, because mark rowe decided SIEG HEIL! I AM GOD! YOU WILL OBEY MY WHIM
AND I HAVE DICTATED THAT YOU ARE AN IGNORAMUS WHO NEEDS TO BE TAUGHT A LESSON
and unfortunately every free software project that tries to use the gtk
gobject bindings will encounter serious fundamental problems as a result
of his bullying.
> More flexible
> because you could use it from any language with gobject-introspection
> bindings. More consistent with the rest of the stack.
really - don't do it. see the message earlier. i'm sorry i didn't
participate in this discussion earlier when it was first underway: i
simply didn't know that this discussion was even taking place.
> > 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.
other than the fundamental programming errors and subtle flaws, yes.
> The hardest case are activities which implement their content view in
> html and the rest using native widgets.
this is why, approximately 2 years ago, i recommended that the OLPC
project turn the entire SUGAR environment on its head, and convert
whole-sale to pyjamas-desktop.
when the native widgets *are* HTML/DOM-based widgets, there *is* no
however, with access to the python-DOM, there is at least some tricks
that you can play, such as creating python callbacks that respond to
events on the bits of HTML (mouse-over, mouse-click) etc.
i can show you how to do that *without* having to have the pyjamas-desktop
infrastructure, but please for god's sake don't use the gobject-introspection
code to try it, you *will* end up with an unstable application.
> 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.
it's actually fun :)
> 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.
yyyyes you caaaaan :) take a look at pyjamas Canvas widget.
ok, it depends what you mean by "canvas" - if you mean SVG Canvas as in
HTML5 SVG DOM-controlled Canvas, yes you can.
> * 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.
not if you convert everything to be a client-server architecture using
JSONRPC it isn't. i also recommended this (2 years ago) in the proposal.
> practical/low cost solution.
no, it is not a "bit of a hack", it is the absolute worst possible thing
that you could even remotely possibly consider.
it's a one-way trap, basically. there is no way to get the execution results
back out, except by *shudder* polling bits of hidden DOM that you store the
> WebKitGtk doesn't seem to have something
> should be easy to add.
yeah... it's not. ok, it is - but then you have to convert the return
result into something meaningful in python.
the projects that i know of that have done this are pyv8 and
python-spidermonkey. pyv8 uses libboost to help with the conversion
(including exceptions, amazingly!) and python-spidermonkey is much less
mature, but is functional.
> I'm not sure about browser -> application
DOM events. pythonwebkit allows you to drop python callbacks onto
*any* event type, from onload at the document level to onresize at the
window level to onclick and even onxmlhttprequest AJAX responses.
it's actually quite straightfoward, but you have to really think
through pythonwebkit there are 350 DOM objects now available to you,
with over 3,000 DOM functions and over 20,000 DOM properties and
approximately 100 different types of events.
> 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.
JSON messages (in a hidden iframe!) was how i envisaged being able to
More information about the Sugar-devel