[Sugar-devel] Browse and the move to WebKit

[Luke Kenneth Casson Leighton]

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
 form.

 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 
 comprehended.


> > 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.

 that's incorrect.  i wrote the direct python bindings over a year ago:
   http://www.gnu.org/software/pythonwebkit

 the gobject bindings approach is fundamentally flawed and unfortunately
 you will not find this out until you begin to try *significant* usage of the
 DOM.

 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:
 pyjamas-desktop.

 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.

 and it's necessary!  you simply cannot have javascript-equivalent python
 bindings to the DOM that are not fully without fail absolutely cast-iron
 guaranteed without one single exception absolutely and 100% identical _to_
 the javascript bindings.

 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
 such problem.

 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.


> * Injecting javascript is a bit of an hack but it might be a
> 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
 results of the execution of whatever javascript functions were called.


> WebKitGtk doesn't seem to have something
> like iOS stringByEvaluatingJavaScriptFromString but it looks like it
> 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
> communication,

 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
 "outside the box", where the box is "javascript is god, javascript
 is isolated, javascript is the world" and start realising that
 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
 communicate with javascript in pyjamas-desktop.  it's tricky as hell
 though.

 l.