[Sugar-devel] webkit, hulahop; developing apps using browser engine DOM for widgets

[Luke Kenneth Casson Leighton]

On 6/9/09, Bobby Powers <bobbypowers at gmail.com> wrote:
> Hi Luke

 hallooo
> Actually, I believe Jan, the pywebkitgtk maintainer, started off with
>  OLPC's Browse activity for that demo.  He then modified it to use the
>  new webkit bindings instead of hulahop ones.

 ahh, that would explain the copyright messages still being there

> OLPC has always used
>  hulahop, although I worked a little on a proof of concept browser
>  activity using webkit a few months ago (
>  http://git.sugarlabs.org/projects/browse/repos/webkit ).

 ahh.  ok.  cool.  in browser.py i see you commented out
addEventListener.  in the new glib / gobject bindings, that's ineptly
named add_event_listener for elements:

    if bits:
        element.connect("browser-event", lambda x,y,z: _dispatchEvent(y))
    if (bits & 0x00001):
        element.add_event_listener("click", True)

and ineptly named add_window_event_listener, for the window-based one:

    mf.connect("browser-event", browser_event_cb) # yuk.  one signal? oh well..
    mf.add_window_event_listener("click")
    mf.add_window_event_listener("change")
    mf.add_window_event_listener("mouseout")

not perfect, but hey, it works.  i was advised to use sub-signal names
otherwise it gets rather messy.

an ideal situation is one where a slightly higher-level API is created
which makes all these things look the same, i.e. as done with this:

   http://paul.giannaros.org/pykhtml/

basically he took the python bindings to KHTML (which are
auto-generated from c++ and are a bit of a mess) and tidied them up
using some wrapper classes.

the xpdom classes are better - and virtually identical to pykhtml -
_once_ you get past the initial mozilla COM interface crap.

the webkit glib/gobject bindings and pywebkitgtk are both
auto-generated and so access to DOM is via two levels of crud, and
there are conventions to glib / gobject (stupid lower-casing) that is
contrary to the W3C specification.  _that_ can be worked around with
an extra level of indirection.

once done, you'd be able to pretty much drop the exact same olpc
browser onto KHTML, webkit or xul.  and, other than the c++
rtti-related bugs in KHTML, you'd get exactly the same functionality.

>  The problem
>  was that at the time, none of the packages in Ubuntu/Fedora/Debian
>  included the new gobject download API, so it was of limited usability.

 ah - i do have pre-built packages for amd64 of webkit #16401.master:

 http://sourceforge.net/project/showfiles.php?group_id=236659

 those are built from a version around aug 2008, i'm just in the
process of syncing to the latest revision of webkit.

l.