Talk:Webkit backend for Hulahop

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.

I've voted on that webkit bug, that's about as much as I can do. If it doesn't get accepted, it's just annoying, not dealbreaking. Distros will manage this.

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.

It would be very cool, but sugar.graphics is a very leaky abstractions, pretty much all activities use GTK widgets too. When it gets more GTK-agnostic, web-engine would be a very interesting platform (next to Qt, Android and Swing).