Difference between revisions of "Talk:Webkit backend for Hulahop"

From Sugar Labs
Jump to: navigation, search
(describe that python DOM bindings to pywebkitgtk have already been done)
Line 1: Line 1:
 
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? [[User:Homunq|Homunq]] 01:09, 31 March 2009 (UTC)
 
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? [[User:Homunq|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. [[User:Lucian|Lucian]] 06:23, 1 April 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. [[User:Lucian|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.

Revision as of 08:45, 2 July 2009

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.