[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

[bugzilla-daemon at webkit.org]

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





------- Comment #137 from lkcl at lkcl.net  2009-02-11 06:17 PDT -------
(In reply to comment #134)
> Created an attachment (id=27558)
 --> (https://bugs.webkit.org/attachment.cgi?id=27558&action=view) [review]
> Vala bindings generator
> 
> Here's an archive containing a few metadata files and a Makefile that can
> generate Vala bindings for the GObject DOM binding built using my last patch.

 _brilliant_.  it will be interesting to look at that.

 if you would like me to investigate porting pyjamas-desktop to Vala,
 i _will_ however need a full set of DOM bindings - compliant with the
 _full_ de-facto DOM standard (not the to-the-letter W3C standard).

 code that does this:

 def setWidth(node, width):
    try:
       type = node.type
    except GobjectPropertyError:
       type = None
    if type == 'embed':
       if isinstance(width, str):
          if width[-2:] == 'px':
              width = int(width[:-2])
          else:
              # assume it's an int
              try:
                 width = int(width)
              except:
                 raise "Your user probably tried setting width = '5%' or '5em'
which is not in the W3C standard nor the de-facto javascript-led standard."

    # finally, we can get down to actually setting the width,
    # after detecting and converting it from (possibly a) string
    # to an int, thanks to mark rowe of apple insisting that users of
    # language bindings to webkit must be responsible for ensuring
    # compliance to standards, rather than making life easier by
    # conforming to de-facto javascript-driven standards

    gdom_node_set_property(node, "width", width) # something like this.

and the equivalent in VALA, is out of the question.

this is of course quite clearly ridiculous, and, worse, imposes a
run-time performance penalty on applications, as they detect and
protect users from expecting the framework to conform to de-facto
javascript-driven standards and the users get a nasty shock and
find otherwise.

repeat for toString (the other de-facto javascript-driven standard
function)

so if the vala bindings can provide the _full_ de-facto javascript-driven
standard functionality, i can look at expanding the usefulness of the
vala bindings by providing higher-level abstraction classes, and a
port of pywebkitgtk's "runner" infrastructure (see demobrowser.py)
to allow people to write generic apps, in VALA, that perform DOM model
manipulation.





> Some of the files here are derived from vapi/packages/webkit-1.0 in the Vala
> sources.  The Makefile has to generate the bindings in a 2-stage process since
> the DOM classes have a different prefix than other WebKit/GTK classes.
> 
> I agree that Python bindings are important and that it would be wise to choose
> a prefix that makes python-pygobject happy.  Given this, I now think that
> reasonable candidates for the name of a class representing the DOM Element
> interface are

 ok - just to point out: it's not a "DOM Element" interface, it's a "DOM"
 interface.  "DOM Element" is a (substantial) sub-portion of the "DOM"
 interface.

 there is much more in the DOM W3C standard (and the de-facto
javascript-driven)
 standard than just "DOM Elements"

 sorry to be pedantic about this, but it's important to clarify.

 do you _mean_ "just rename that part of the gobject bindings which refers
 solely, specifically and exclusively to DOM Elements, leaving out DOM Window,
 DOM Frame, DOM Node, DOM Events", or did you mean to say:

"Given this, I now think that reasonable candidates for the name of a
class representing the DOM interface are:

  Gdom
  WebKit
  WebKitDom

"

 assuming yes, carry on :)

> With either of the last two, we could use vanilla Vala bindings generation
> rather than the 2-stage process in this Makefile.

 it looks like "WebKit" is the most sensible choice, overall.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.