Talk:Webkit backend for Hulahop

From Sugar Labs
Revision as of 08:45, 2 July 2009 by Lkcl (talk | contribs) (describe that python DOM bindings to pywebkitgtk have already been done)
Jump to navigation Jump to 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 code.google.com 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.