Talk:Webkit backend for Hulahop

From Sugar Labs
Revision as of 09:45, 2 July 2009 by Lkcl (talk | contribs) (describe that python DOM bindings to pywebkitgtk have already been done)
Jump to: navigation, search

I'm confused. Wouldn't it ruin the whole idea if you had to change the Hulahop API? The idea is to make gecko/xulrunner and webkit interchangeable using an existing, standard API, right? Homunq 01:09, 31 March 2009 (UTC)

Changes are supposed to be as non-invasive as possible, but some would be needed. I was thinking that since Browse is the only major consumer of Hulahop, it wouldn't be a problem as long as it still worked. Lucian 06:23, 1 April 2009 (UTC)

Lucian, i've already added the python DOM bindings to pywebkitgtk that you will need in order to complete this work. I've also recently added a wrapper script that makes the two (hulahop and pywebkitgtk) look near-identical. You will need to bitch like mad at apple and will need to add your voice to those wishing to see the necessary glib / gobject bindings added into webkit. If you do not, it will be believed that i am the only person who would like to see this happen and i have been treated with the utmost enormous amount of disrespect and arrogance that only a billion dollar company can muster. see bug #16401 on webkit and bug #13 on pywebkitgtk for the necessary patches.

also btw the pywebkitgtk and also the hulahop engines are actually sufficiently powerful to actually _replace_ the sugarlabs graphics engine, which is currently written in a hybrid of c and python, with pure python. which would be very cool.