add bindings to DOM model (requires patch to webkit)

[GoogleCodeExporter]

https://bugs.webkit.org/show_bug.cgi?id=16401

patch also includes javascript execution of #12 which _may_ end
up being superceded - POSSIBLY - by the DOM model handling.

Original issue reported on code.google.com by luke.lei...@gmail.com on 27 Aug 2008 at 8:12

Attachments:

• f

[GoogleCodeExporter]

update.

Original comment by luke.lei...@gmail.com on 29 Aug 2008 at 8:27

Attachments:

• psd

[GoogleCodeExporter]

update.

Original comment by luke.lei...@gmail.com on 1 Sep 2008 at 12:27

Attachments:

• psd

[GoogleCodeExporter]

Original comment by jmalo...@gmail.com on 27 Oct 2008 at 11:58

• Changed state: Accepted

[GoogleCodeExporter]

updated patch which splits out DOM-specific bindings into webkit_glib.defs
also up-to-date for webkit svn as of about dec 2008.

Original comment by luke.lei...@gmail.com on 9 Jan 2009 at 12:25

Attachments:

• f

[GoogleCodeExporter]

Hi ,    
I applied the patch f 160 KB but I got this error when compiling :

cd . && automake-1.9 --foreign  Makefile
/bin/sh: line 11: automake-1.9: command not found
make: *** [Makefile.in] Erreur 127

any idea please , 

Original comment by houda.Qt4@gmail.com on 29 Jan 2009 at 3:29

[GoogleCodeExporter]

hiya,
that looks like you don't have automake-1.9 installed (?)
what is in line 11?  which file?

i think you should be re-running ./autogen.sh

also - you _have_ got the patched version of webkit-glib, yes?

bug #16401

if not, go get the latest code from 
http://github.com/lkcl/webkit/tree/16401.master

Original comment by luke.lei...@gmail.com on 29 Jan 2009 at 4:10

[GoogleCodeExporter]

Doesn't seem like a good idea to rely on branch of webkit, since WebView already
exposes a DOMDocument in the ObjC backend.* Seems better to try to get the 
C/GTK port
to implement it.

____

*
http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/WebKit/Classes/WebView_
Class/Reference/Reference.html#//apple_ref/occ/instm/WebView/mainFrameDocument

Original comment by MonkeeS...@gmail.com on 23 Apr 2009 at 2:50

[GoogleCodeExporter]

the objective-c backend is proprietary and specific to the proprietary apple
operating system.  it is therefore of absolutely no value to anyone but apple.

if you would like to help, you could help get the patch to webkit into webkit.

Original comment by luke.lei...@gmail.com on 23 Apr 2009 at 9:25

[GoogleCodeExporter]

The ObjC backend is not proprietary to Apple, they released it to WebKit. They 
have
their own proprietary branch, but the WebKit branch is BSD licensed.* I just 
linked
to the Apple docs because WebKit doesn't have any standardized API docs. The 
Windows
backend also implements the same interface.** I didn't mean to say that the 
patch(s)
in the WebKit bug tracker shouldn't be supported. I've not reviewed them, or the
comments (quite a few of both!) I only meant that it doesn't seem like a good 
idea to
rely on a forked version of WebKit with pywebkit, since, for example, it will 
break
if you deploy with a custom-built pywebkit to a system with vanilla WebKit.

____

* http://webkit.org/coding/bsd-license.html
** http://trac.webkit.org/browser/trunk/WebKit/win/Interfaces/IWebView.idl

Original comment by MonkeeS...@gmail.com on 24 Apr 2009 at 2:30

[GoogleCodeExporter]

Issue 29 has been merged into this issue.

Original comment by jmalo...@gmail.com on 28 May 2009 at 9:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Is this patch integrated into pywebkitgtk? I assume the patches listed above 
from
2008 are in, but, what about the latest one from Jan 9, 2009?

Original comment by sneil...@gmail.com on 4 Jun 2009 at 2:42

[GoogleCodeExporter]

monkeysage: all the more reason, then, as to why you should, if you would like 
to use
python bindings to webkit, that you should get onto the webkit mailing lists, 
get on
to the webkit irc, get on to the webkit bug tracker and continuously request 
for an
explanation as to why this patch is being delayed.

Original comment by luke.lei...@gmail.com on 4 Jun 2009 at 8:37

[GoogleCodeExporter]

sneilan1: no, and it cannot be integrated, until the patch to webkit is 
integrated. 
the reason is very very simple: there are 1,500 functions added (all 
automatic), none
of which are there until the patch to webkit is integrated.

therefore, you must get onto the webkit mailing lists, get on to the irc, get 
on to
the webkit bug tracker and continuously request explanations for the delay and
express your support for the removal of delays to the integration of the patch.

Original comment by luke.lei...@gmail.com on 4 Jun 2009 at 8:38

[GoogleCodeExporter]

Hey y'all! We're aware of this issue. The DOM bindings is one of the tasks in 
the
priority list, and I myself are slowly going through those (Accessibility 
support
comes to mind as well as API work). If this is something really important to 
you, I
encourage you to look at the DOM bindings patch in bugs.webkit.org and help out 
with
the effort. There's a fairly detailed comment on that patch as to what needs to 
be
done first, and people are willing to review patches to get it started!

And please, don't annoy people on the list. It's counter-productive. Everyone's
already busy as it is. Contribute if you must!

Original comment by jmalo...@gmail.com on 4 Jun 2009 at 11:19

[GoogleCodeExporter]

Original comment by jmalo...@gmail.com on 4 Jun 2009 at 11:20

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

OK, I'll definitely do that. Didn't mean to annoy you guys, I was just curious,
although, now I see the depth of the problem and why ya'll might've been 
annoyed.

Original comment by sneil...@gmail.com on 4 Jun 2009 at 3:13

[GoogleCodeExporter]

hiya jmalonzo,

apple's employees have made unacceptable dictatorial decisions that render the 
webkit
gdom bindings near useless.  they raise issues with the patch, which i counter, 
and
then they IGNORE rather than accept the counter-arguments, preferring to stick 
with
"their way".

this is totally unacceptable, and the more people that tell them so, the better.

then, there was the totally disrespectful attitude towards the project that 
inspired
these python bindings (pyjd) and the totally disrespectful attitude towards 
myself. 
the lack of respect allowed all progress to be dismissed, which is of course 
what
apple's employees want: total control and a situation in which _they_ are in 
control.

unfortunately, a number of people actually listened to apple, and ended up 
wasting
their time.  the latest group was the people who took on the Vala bindings.  
they
listened to apple, and ended up getting themselves into an awful mess.  the 
result
was that they had to abandon contributions to the project.

unfortunately, because they listened to apple, they REMOVED a large section of
absolutely critical functionality (event handling) which meant that anything 
that
they did from that point onwards was useless.

imagine if someone did an implementation of javascript DOM bindings, but without
onload, onclick, onkeypress etc, and without XMLHTTPRequest asynchronous 
callbacks.

so - i am starting again, unfortunately ignoring everything that they've done, 
and am
forward-porting the patch.

i'm giving serious consideration to creating a completely separate library.

Original comment by luke.lei...@gmail.com on 4 Jun 2009 at 4:13

[GoogleCodeExporter]

ok - this is an update which matches the current #16401.master update to the
webkit/gdom branch.  the revision of webkit that it was updated to was r44473.
the matching webkit fork is available from:
http://github.com/lkcl/webkit/tree/16401.master

Original comment by luke.lei...@gmail.com on 23 Jun 2009 at 1:35

Attachments:

• f

[GoogleCodeExporter]

new version of patch which thanks to kees bos is the beginnings of remapping
stupid_glib_naming_convention to properW3CStandardNaming.

Original comment by luke.lei...@gmail.com on 26 Jun 2009 at 7:56

Attachments:

• f

[GoogleCodeExporter]

... btw, obviously, that involves renaming webkit.so to _webkit.so.  webkit.py 
is now
auto-generated by create_webkit_wrapper.py - yes, i know, there are better ways 
to do
this but this is a first shot.
l.

Original comment by luke.lei...@gmail.com on 26 Jun 2009 at 8:02

[GoogleCodeExporter]

ok another update.  i've added a few extra properties and a couple of functions.
the auto-generated remapper now works really well.  event handling is a _little_
awkward, and ideally needs a bit more work to be made more like e.g. 
python-xpcom.
the auto-generated webkit.py is 70,000 lines but that can't be helped.  i'd like
to think of a way to do that dynamically, but right now this "works".

to make changes, you MUST install _webkit.so a first time and THEN run
create_webkit_wrapper.py because it does "import _webkit".

or put build/.libs into the python path somehow.  all very awkward.

Original comment by luke.lei...@gmail.com on 11 Jul 2009 at 3:11

Attachments:

• f

[GoogleCodeExporter]

@luke.leighton

compile failed

{{{
make[1]: Entering directory `/home/huahua/debs/webkit/pywebkit/r70'
(cd . \
     && /usr/bin/pygobject-codegen-2.0 \
        --register /usr/share/pygtk/2.0/defs/gdk-types.defs \
        --register /usr/share/pygtk/2.0/defs/gtk-types.defs \
        --override webkit.override \
        --prefix pywebkit webkit.defs) 2>&1 >gen-webkit.c | tee webkit.errors \
    && ! grep -q -v "^\*\*\*INFO\*\*\*" webkit.errors \
    && cp gen-webkit.c webkit.c \
    && rm -f gen-webkit.c
/usr/share/pygobject/2.0/codegen/definitions.py:42: DeprecationWarning:
object.__init__() takes no parameters
  str.__init__(self, type_name)
***INFO*** There are no declared global functions.
***INFO*** The coverage of methods is 100.00% (410/410)
***INFO*** There are no declared virtual proxies.
***INFO*** There are no declared virtual accessors.
***INFO*** There are no declared interface proxies.
make[1]: *** [webkit.c] Error 1
make[1]: Leaving directory `/home/huahua/debs/webkit/pywebkit/r70'
make: *** [all] Error 2
Command exited with non-zero status 2

}}}

Original comment by jhuangjiahua@gmail.com on 12 Jul 2009 at 8:04

[GoogleCodeExporter]

 jhuangjiahua, hi,

 you'll need the absolute latest version of #16401.master off of github: please
confirm that you have done a "git pull" from
http://github.com/lkcl/webkit/tree/16401.master within the past 24 hours.

also, can you get a complete compile listing - "error in webkit.c" is of 
absolutely
no use to anyone.  i suspect that code.google.com is interfering.  if it is, 
please
place the compile output somewhere where it can be downloaded without 
interference
(perhaps as an attachment).

l.

Original comment by luke.lei...@gmail.com on 12 Jul 2009 at 11:24

[GoogleCodeExporter]

ok i've prepared an update, to the latest svn revision.
again, you will need to get latest svn of pywebkitgtk
and latest git pull of #16401.master.

that _should_ fix any build issues.

Original comment by luke.lei...@gmail.com on 12 Jul 2009 at 5:50

Attachments:

• f

[GoogleCodeExporter]

ok - another update.  this one is for svn revision r46395.

Original comment by luke.lei...@gmail.com on 26 Jul 2009 at 10:36

Attachments:

• pywebkitgtk.patch

[GoogleCodeExporter]

I believe Luke's path has been integrated into webkit now.
https://bugs.webkit.org/show_bug.cgi?id=33590

Should this patch now be integrated into pywebkitgtk ?

Original comment by sarvil...@gmail.com on 6 Jun 2010 at 6:37

[GoogleCodeExporter]

i've just gone over webkit 33590, taking a quick look at it, and i find that 
there are 
significant features missing, such as event handling.  that means that as it 
stands, 
the patch is _not_ going to apply: it is specifically dependent on what 
functions are 
available via glib/gobject bindings.  it will be necessary to re-run h2defs.py 
to re-
generate the .defs file, removing the auto-generated functions on which the 
last-
submitted patch applies.

Original comment by luke.lei...@gmail.com on 6 Jun 2010 at 8:47

[GoogleCodeExporter]

I've regenerated a webkitdom.defs file based on the bindings that's available 
upstream. Code's currently in http://github.com/jmalonzo/pywebkitgtk/.

To use it, get the Document by calling WebView.get_dom_document and take it 
from there. Unfortunately, the only documentation atm is the .defs file.

Cheers.

Original comment by jmalo...@gmail.com on 23 Oct 2010 at 9:10

• Changed state: Started