[Sugar-devel] Browse and the move to WebKit

[lkcl luke]

[mozilla people, please feel free to skip to the bottom of this, for
the conclusion - the rest is detail]

right: i've just learned something very exciting: one of the pyjamas
contributors, a very intelligent individual, anthony, has been working
with the webkit-gtk team to create a gobject-introspection port of
pyjamas-desktop.  he has a number of the examples already working.

to emphasise the significance of this:

* the damaged event handling which was added in by the webkit gtk team
3 years ago (without design consultation, after mark rowe ordered the
removal of the original fully-working event handling without good
justification) has been removed.

 the new event handling infrastructure is, i gather, no longer
dependent *at all* on gobject signals.  it should be along the exact
same lines as the pythonwebkit bindings: a direct callback, directly
called from the webkit event infrastructure.

 that means that event callbacks will no longer result in race
conditions, instability and so on, which i warned you about, last
week.

* anthony has direct first-hand experience of what's needed to make
the gobject bindings actually useful and useable.  he will therefore
be able to explain to the webkit-gtk team why mark rowe's
under-informed objections to various absolutely essential features
are, in fact, absolutely essential.  in the intervening years (!!  i
can't quite get over the fact that the original work was done in
2008...) the webkit-gtk team may have actually encountered some of the
problems themselves.


the bottom line is that i have much more confidence in the
webkit-gobject bindings, thanks to anthony's involvement, that anthony
can help the webkit-gtk team to stabilise the webkit-gobject bindings,
through the use of pyjamas-desktop as a massively-comprehensive 100%
code-coverage testing environment.  it is therefore *not* my
recommendation that the OLPC team revert to the use of python-hulahop
for their web browser "activity".

this effectively leaves the python-hulahop code completely orphaned,
and only relevant to the pyjamas-desktop "xulrunner" port.

the question is, therefore: is it useful for the mozilla foundation to
have a second test environment - by way of having the pyjamas-desktop
"xulrunner" port still active?  the reason i ask is because as has
been demonstrated by that window focus bug, it looks like there's some
memory corruption which has been completely missed, thanks to the
narrow "drive" of the mozilla foundation to concentrate exclusively on
firefox releases.  but if the testing via hulahop was included on a
regular basis, by the mozilla foundation, then it is not hard to
conclude that that memory corruption bug would have been noted and
fixed much earlier.

l.