Bug 16401

Summary:

[GTK] GObject/C DOM binding

Product:

WebKit

Reporter:

Alp Toker <alp>

Component:

WebKitGTK

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED DUPLICATE

Severity:

Normal

CC:

a9016009, adam, andrew, christian, cosimoc, ddkilzer, donsoto, gustavo, i.am.dumb, jason.ribeiro, jmalonzo, kevin, lkcl, mbarnes, sam, sascha.dewald, sbillaudelle, sean, tvignaud, xan.lopez, xfdbse, zuh

Priority:

Keywords:

Gtk

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Bug Depends on:

21392, 22528, 27410, 27424, 27425, 27426, 27427, 27428, 27429, 27430, 27431, 27432, 27433, 27434, 27435, 27436, 28042, 28096, 28097, 28098, 28099, 28101, 28102, 28103, 28104, 28105, 28106, 28107, 28109, 28110, 28111, 28228

Bug Blocks:

16686, 20586, 20896, 20897, 20898, 26302

Attachments:

Description	Flags
Beginnings of the generator script	none
adds javascript-execution and eval to DOM model	none
adds beginnings of WebKitEvent class, for "browser event" notification	none
progress on generator script	none
progress on generator script	none
working access to DOM model from pywebkitgtk!	none
property getting added, with stubs for setting.	none
property getting added, property set strings added, hash-map added	none
added LANGUAGE_GOBJECT	none
bug-fixing LANGUAGE_GOBJECT	none
add_event_listener for element events; added defaultView	none
big tidyup, no manual compile intervention required	none
respect file conventions, remove tabs	none
resolve conflict in latest svn with webkitwebframe.cpp	none
add webkitevent.h	none
added start of XMLHttpRequest handling	none
tidyup and adding correct access to DOMWindow	none
use "detail" on signals	none
updated ChangeLogs	none
lkcl-review, coding standards	alp: review-
updated fixing review requests	none
more review fixing	none
merged PrivateGdom.cpp into Gdom.cpp	mrowe: review-
updated for many of mrowe's comments	none
massively (oversimplified, unfortunately) reduced patch	none
remainder of patch bringing gdom patch up to full functionality	none
updated massively-reduced functionality patch	none
converts upper-case GdomXyzAbc to gdom-xyz-abc	none
last patch - end of current available time and resources	none
DOM patch updated to version 37602	none
DOM patch updated to version 38852	none
patch for martin to add	none
add gdom_event_target_node_dispatch_event()	none
DOM patch with lots of fixes, updated to revision 40813	none
Vala bindings generator	none
GdomHTMLTableRowElement.cpp	none
GdomHTMLTableRowElement.h	none
GdomAttr.cpp	none
GdomAttr.h	none
GdomAttrPrivate.h	none
GdomHTMLTableRowElementPrivate.h	none
new patch, updated to revision 41018	none
GTK DOM bindings	none
patch updated to revision 42662	mrowe: review-
brings glib/gobject bindings up to svn r44473.	jmalonzo: review-
answering comments in #194 by sam	jmalonzo: review-
the monster (complete patch) updated to r46395, including reflected properties	none

Alp Toker

Reported 2007-12-11 09:25:52 PST

The GTK+ port needs a public API binding of the DOM. The COM binding generator is a reasonable starting point. The details of how to map the DOM to GObject have yet to be discussed.

Attachments
Beginnings of the generator script (5.58 KB, patch) 2008-07-11 06:27 PDT, Alp Toker	no flags	Details Formatted Diff Diff
adds javascript-execution and eval to DOM model (44.62 KB, patch) 2008-08-20 07:19 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
adds beginnings of WebKitEvent class, for "browser event" notification (11.02 KB, patch) 2008-08-21 10:19 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
progress on generator script (70.78 KB, patch) 2008-08-23 14:11 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
progress on generator script (6.14 KB, patch) 2008-08-23 15:41 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
working access to DOM model from pywebkitgtk! (139.47 KB, patch) 2008-08-27 01:02 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
property getting added, with stubs for setting. (148.80 KB, patch) 2008-08-27 12:57 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
property getting added, property set strings added, hash-map added (210.25 KB, patch) 2008-08-29 07:28 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
added LANGUAGE_GOBJECT (217.23 KB, patch) 2008-08-30 12:47 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
bug-fixing LANGUAGE_GOBJECT (219.73 KB, patch) 2008-08-30 14:57 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
add_event_listener for element events; added defaultView (227.44 KB, patch) 2008-08-31 10:19 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
big tidyup, no manual compile intervention required (253.44 KB, patch) 2008-08-31 17:05 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
respect file conventions, remove tabs (256.54 KB, patch) 2008-09-01 03:41 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
resolve conflict in latest svn with webkitwebframe.cpp (256.69 KB, patch) 2008-09-01 13:13 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
add webkitevent.h (258.90 KB, patch) 2008-09-01 13:19 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
added start of XMLHttpRequest handling (267.45 KB, patch) 2008-09-02 08:15 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
tidyup and adding correct access to DOMWindow (279.13 KB, patch) 2008-09-03 14:20 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
use "detail" on signals (280.26 KB, patch) 2008-09-04 12:04 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
updated ChangeLogs (277.08 KB, patch) 2008-09-12 07:16 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
lkcl-review, coding standards (277.13 KB, patch) 2008-09-12 07:28 PDT, Luke Kenneth Casson Leighton	alp: review-	Details Formatted Diff Diff
updated fixing review requests (273.00 KB, patch) 2008-09-14 04:44 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
more review fixing (240.56 KB, patch) 2008-09-15 06:34 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
*merged PrivateGdom.cpp into Gdom.cpp* (231.24 KB, patch) 2008-09-15 07:35 PDT, Luke Kenneth Casson Leighton	mrowe: review-	Details Formatted Diff Diff
updated for many of mrowe's comments (236.68 KB, patch) 2008-09-16 14:19 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
massively (oversimplified, unfortunately) reduced patch (76.35 KB, patch) 2008-09-17 14:28 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
remainder of patch bringing gdom patch up to full functionality (172.67 KB, patch) 2008-09-18 09:10 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
updated massively-reduced functionality patch (75.59 KB, patch) 2008-09-18 13:42 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
converts upper-case GdomXyzAbc to gdom-xyz-abc (1.44 KB, text/plain) 2008-09-19 13:18 PDT, Luke Kenneth Casson Leighton	no flags	Details
last patch - end of current available time and resources (225.46 KB, patch) 2008-09-25 12:02 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
DOM patch updated to version 37602 (220.59 KB, patch) 2008-10-16 09:36 PDT, Martín Soto	no flags	Details Formatted Diff Diff
DOM patch updated to version 38852 (192.50 KB, patch) 2008-11-30 15:30 PST, Martín Soto	no flags	Details Formatted Diff Diff
patch for martin to add (5.42 KB, patch) 2008-12-02 09:10 PST, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
add gdom_event_target_node_dispatch_event() (1.89 KB, patch) 2008-12-15 03:40 PST, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
DOM patch with lots of fixes, updated to revision 40813 (115.98 KB, patch) 2009-02-10 20:12 PST, Adam Dingle	no flags	Details Formatted Diff Diff
Vala bindings generator (8.91 KB, application/x-bzip) 2009-02-11 05:07 PST, Adam Dingle	no flags	Details
GdomHTMLTableRowElement.cpp (14.40 KB, text/plain) 2009-02-13 01:12 PST, Xan Lopez	no flags	Details
GdomHTMLTableRowElement.h (3.63 KB, text/plain) 2009-02-13 01:13 PST, Xan Lopez	no flags	Details
GdomAttr.cpp (7.27 KB, text/plain) 2009-02-13 01:14 PST, Xan Lopez	no flags	Details
GdomAttr.h (2.04 KB, text/plain) 2009-02-13 01:15 PST, Xan Lopez	no flags	Details
GdomAttrPrivate.h (1.39 KB, text/plain) 2009-02-13 01:33 PST, Xan Lopez	no flags	Details
GdomHTMLTableRowElementPrivate.h (1.49 KB, text/plain) 2009-02-13 01:34 PST, Xan Lopez	no flags	Details
new patch, updated to revision 41018 (107.90 KB, patch) 2009-02-18 14:28 PST, Adam Dingle	no flags	Details Formatted Diff Diff
GTK DOM bindings (110.80 KB, patch) 2009-03-06 17:49 PST, Jim Nelson	no flags	Details Formatted Diff Diff
patch updated to revision 42662 (112.45 KB, patch) 2009-04-21 17:06 PDT, Adam Dingle	mrowe: review-	Details Formatted Diff Diff
brings glib/gobject bindings up to svn r44473. (207.61 KB, patch) 2009-07-12 14:28 PDT, Luke Kenneth Casson Leighton	jmalonzo: review-	Details Formatted Diff Diff
answering comments in #194 by sam (3.84 KB, patch) 2009-07-15 13:58 PDT, Luke Kenneth Casson Leighton	jmalonzo: review-	Details Formatted Diff Diff
the monster (complete patch) updated to r46395, including reflected properties (210.46 KB, patch) 2009-07-25 15:10 PDT, Luke Kenneth Casson Leighton	no flags	Details Formatted Diff Diff
Show Obsolete (34) View All Add attachment proposed patch, testcase, etc.

Alp Toker

Comment 1 2008-07-11 06:27:49 PDT

Created attachment 22247 [details] Beginnings of the generator script Just a start

Luke Kenneth Casson Leighton

Comment 2 2008-08-20 07:19:51 PDT

Created attachment 22894 [details] adds javascript-execution and eval to DOM model about = "<html><body id='body'></body></html>" self._browser.load_string(about, "text/html", "iso-8859-15", "about:") self.show_all() def js_test(self): main_frame = self._browser.get_main_frame() print dir(main_frame) ctx = main_frame.gjs_get_global_context() print dir(ctx) doc = ctx.get_by_name("document") print doc, dir(doc) doc.fred = 5 print doc.fred win = doc.get_by_name("window") print win, dir(win) print doc.get_by_name("fred") print doc.get_by_name("joe") #doc.eval("para = document.createTextNode('Some content.');") ctx.eval("console.error('hello');") doc.execute("document.getElementById('body').appendChild(document.createTextNode('Some content.'));") #doc.execute("document.appendChild(document.createTextNode('Some content.'));") #doc.execute("para2 = document.createTextNode('Some content.');") #para = doc.get_by_name("para") #print "para", para, para.get_string() #doc.execute("document.appendChild(para);") def _set_title(self, title): self.props.title = title def _loading_start_cb(self, view, frame): main_frame = self._browser.get_main_frame() if frame is main_frame: self._set_title(_("Loading %s - %s") % (frame.get_title(),frame.get_uri())) self._toolbar.set_loading(True) def _loading_stop_cb(self, view, frame): # FIXME: another frame may still be loading? self._toolbar.set_loading(False) self.js_test()

Mark Rowe (bdash)

Comment 3 2008-08-20 16:05:50 PDT

Comment on attachment 22894 [details] adds javascript-execution and eval to DOM model This patch does not seem to be for WebKit. Why is it here?

Luke Kenneth Casson Leighton

Comment 4 2008-08-20 16:23:03 PDT

because i am a donut? :) working a bit quick - i worked it out 2 mins _after_ posting :)

Luke Kenneth Casson Leighton

Comment 5 2008-08-21 10:19:22 PDT

Created attachment 22920 [details] adds beginnings of WebKitEvent class, for "browser event" notification event notification - of browser events - as a signal on a WebKitFrame. not sure of direction to take - haven't had any feedback or advice - so am just proceeding anyway. it works.

Luke Kenneth Casson Leighton

Comment 6 2008-08-21 13:16:46 PDT

if anyone's curious, the attachment for the generator script goes here: WebCore/bindings/scripts/CodeGeneratorGObject.pm and you add this: DerivedSources/gdom%.h: DerivedSources/gdom%.cpp; DerivedSources/gdom%.cpp: %.idl $(SCRIPTS_BINDINGS) $(WebCore)/bindings/scripts/CodeGeneratorGObject.pm $(PERL) -I$(WebCore)/bindings/scripts $(WebCore)/bindings/scripts/generate-bindings.pl --include $(WebCore)/dom --include $(WebCore)/html --include $(WebCore)/css --include $(WebCore)/page --include $(WebCore)/xml --include $(WebCore)/svg --outputDir "$(GENSOURCES)" --defines "$(FEATURE_DEFINES_JAVASCRIPT)" --generator GObject $< to WebCore/GNUmakefile.am

Luke Kenneth Casson Leighton

Comment 7 2008-08-23 14:11:17 PDT

Created attachment 22953 [details] progress on generator script * SVG is missed out * TargetEventNode needs review * gdom*private.cpp and gdom*private.h need to be added to GNUmakefile.am technique deployed needs review * rgb colour class needs creation or review: am returning uint32 for now. etc. etc.

Luke Kenneth Casson Leighton

Comment 8 2008-08-23 15:41:38 PDT

Created attachment 22954 [details] progress on generator script * now has private gobject functions in makefile * actually links the library (gosh) so no missing compile dependencies * TODO: derive parent gobject and use it - presently everything's a GOBJECT.

Luke Kenneth Casson Leighton

Comment 9 2008-08-27 01:02:08 PDT

Created attachment 23016 [details] working access to DOM model from pywebkitgtk! it works! i'm amazed :) TODO: lots of the custom functions TODO: add properties.

Luke Kenneth Casson Leighton

Comment 10 2008-08-27 12:57:56 PDT

Created attachment 23038 [details] property getting added, with stubs for setting. added in property "getting" as well, now. "custom" properties missed out and a number of other types as well, but it's a good start. will test property "setting" later. at present you have to do this, to make the whole thing useable and compile (i don't know where to put the files in the Makefile). just after the gdom bindings are auto-generated, ctrl-z the build and do this: cp -aux DerivedSources/gdom*.h WebKit/gtk/webkit/; cp WebCore/bindings/gdom/*.h /usr/local/include/webkit-1.0/webkit/; cp -aux DerivedSources/gdom*.h /usr/local/include/webkit-1.0/webkit/

Luke Kenneth Casson Leighton

Comment 11 2008-08-29 07:28:14 PDT

Created attachment 23068 [details] property getting added, property set strings added, hash-map added this works, and is useable! still have the slightly horrible hack for compilation required, though - to copy the files from DerivedSources/ into /usr/local/includes.

Oliver Hunt

Comment 12 2008-08-29 15:50:10 PDT

Comment on attachment 23068 [details] property getting added, property set strings added, hash-map added Could you remove all the generated files from the patch itself? While obviously we'd like to be able to look at what is being generated, they generated content makes it hard to identify the non-autogenerated content.

Luke Kenneth Casson Leighton

Comment 13 2008-08-30 00:42:00 PDT

there are no auto-generated files included in the patch.

Luke Kenneth Casson Leighton

Comment 14 2008-08-30 00:50:37 PDT

Index: WebCore/bindings/gdom/GDOMHTMLElementWrapperFactory.cpp *sigh* yes - no it's not auto-generated, it's hand-created, _copied_ from the auto-generated JSHTMLElementWrapperFactory.cpp. next version, if you don't make the changes yourself, might say something like, "this file was created cut-and-paste global-search-replace from JSHTMLElementWrapperFactory.cpp. at some point, it might be useful to auto-generate it, although now that the work is done it really doesn't actually matter too much." even better would be for webkit to have some templates such that the JSHTMLElementWrapperFactory, GDOMHTMLElementWrapperFactory, OBJCHTMLElementWrapperFactory, FutureBindingHTMLElementWrapperFactory, PythonHTMLElementWrapperFactory can all benefit from the same very necessary functionality. all of the bindings need a mapping system.

Luke Kenneth Casson Leighton

Comment 15 2008-08-30 12:47:53 PDT

Created attachment 23081 [details] added LANGUAGE_GOBJECT i was accidentally using LANGUAGE_JAVASCRIPT which was fine until i noticed that HTMLInputElement didn't have a setSelectionRange function being auto-generated for the glib bindings. so... it's been necessary to add LANGUAGE_GOBJECT. kind-of inevitable, really. several functions added in to support pyjamas-desktop, which is, perhaps as to be expected, turning out to be quite a comprehensive test tool.

Luke Kenneth Casson Leighton

Comment 16 2008-08-30 14:57:59 PDT

Created attachment 23082 [details] bug-fixing LANGUAGE_GOBJECT a number of functions got deleted by no longer being #ifdef LANGUAGE_JAVASCRIPT. added them back in.

Luke Kenneth Casson Leighton

Comment 17 2008-08-31 10:19:31 PDT

Created attachment 23089 [details] add_event_listener for element events; added defaultView * thanks to darin for the pointer, added add_event_listener (TODO: add remove_event_listener) * added property "defaultView" to GdomDOMDocument

Luke Kenneth Casson Leighton

Comment 18 2008-08-31 17:05:32 PDT

Created attachment 23093 [details] big tidyup, no manual compile intervention required more copyright notices added, big cleanup to get auto-install of header files etc. independent testing greatly appreciated, to make sure i haven't missed anything.

Luke Kenneth Casson Leighton

Comment 19 2008-08-31 17:19:56 PDT

review comments - kept here so as not to lose them, TBD tomorrow: lkcl: and you appear to have slipped some tabs in to the patch along the way ;-) WebKit/gtk/webkit/EventListenerWindow.h -- is that an API header? API headers cannot do that privgdomEventTargetNode.h would make more sense with the suffix of Private, like is done with other private headers why the lower-case prefix on the file names? that doesn't fit our style guidelines you also appear to use GDOM and Gdom... consistencey would be good

Luke Kenneth Casson Leighton

Comment 20 2008-09-01 03:41:12 PDT

Created attachment 23096 [details] respect file conventions, remove tabs addressed mark's concerns and queries: removed rather a lot of tabs changed file names from lower case etc.

Luke Kenneth Casson Leighton

Comment 21 2008-09-01 13:13:10 PDT

Created attachment 23103 [details] resolve conflict in latest svn with webkitwebframe.cpp

Luke Kenneth Casson Leighton

Comment 22 2008-09-01 13:19:40 PDT

Created attachment 23104 [details] add webkitevent.h

Luke Kenneth Casson Leighton

Comment 23 2008-09-02 08:15:14 PDT

Created attachment 23115 [details] added start of XMLHttpRequest handling

Luke Kenneth Casson Leighton

Comment 24 2008-09-03 14:20:54 PDT

Created attachment 23146 [details] tidyup and adding correct access to DOMWindow gdom_dom_window_get_private() was accidentally returning NULL because it was on the TODO list to support GdomDOMWindow. oops.

Luke Kenneth Casson Leighton

Comment 25 2008-09-04 12:04:48 PDT

Created attachment 23173 [details] use "detail" on signals on EventListenerXMLHttpRequest, EventListenerNode and EventListenerWindow, use browser-event::xxxxx "detail" for close, load, resize etc.

Luke Kenneth Casson Leighton

Comment 26 2008-09-12 07:16:13 PDT

Created attachment 23366 [details] updated ChangeLogs

Luke Kenneth Casson Leighton

Comment 27 2008-09-12 07:28:53 PDT

Created attachment 23367 [details] lkcl-review, coding standards

Alp Toker

Comment 28 2008-09-12 21:42:03 PDT

Comment on attachment 23367 [details] lkcl-review, coding standards This is looking good and needs a little more work before we can start to think about getting it landed. These are some of my comments from a first pass review, starting with the trivial / easiest issues to fix. Build fix: The 'KJS' namespace was renamed to 'JSC' recently. Simple search-and-replace in CodeGeneratorGObject.pm gets it building again. Coding style: void: No need for the 'void' in function prototypes like webkit_event_new(void) except in publicly installed C headers. It doesn't matter if the auto-generated C++ sources have the 'void' (since this lets you share the same prototype string with the .h public headers and generated .cpp) but it shouldn't be used in hand-written code. includes: #include <glib-object.h> not #include "glib-object.h" indentation: There are a few places (eg. webkitwebframe.cpp) where 4-space indentation isn't adhered to. It's good to get into the habit of getting this right whenever submitting code to the bug tracker so reviewers can get directly to the technical stuff. Trailing whitespace: There are needless spaces at the ends of lines in both hand-written and auto-generated code that shouldn't be there. Core API changes: webkitevent.h/WebKitEvent: We try to avoid generic type names in the core WebKit/GTK+ public API since 'WebKit.Event' will be ambiguous when 'Gdk.Event' is imported in many OO language bindings. So this could become either WebKitWebEvent, could go into the Gdom namespace or even somehow be merged with GdomEvent (I haven't investigated enough to see if this last suggestion would make sense though). Special-cases for lower_case_conversion: decamelize() is great, but sometimes we'll want to special-case certain character sequences to avoid awkward function names. Right now we get gdom_x_path_exception_to_string() but what we really want is gdom_xpath_exception_to_string(). Some cases I noticed: XPath, WebKit, gdom_htmlbr_element_get_type, gdom_htmld_list_element_get_type _init functions vs. constructors: There are some generated functions like gdom_wheel_event_init_wheel_event(). These should probably be mapped to GObject constructors, ie. gdom_wheel_event_new(). G_PARAM_*: webkitprivate.h defines WEBKIT_PARAM_READABLE and WEBKIT_PARAM_READWRITE replacements for G_PARAM_READABLE and G_PARAM_READWRITE which tell GObject that it doesn't need to copy the input strings to g_param_spec(). It's probably worth reusing this (or copying equivalents into gdomprivate.h or similar). Build system: The large lists in these files should be auto-generated by the build system: gdom.h gdomdefines.h GDOMHTMLElementWrapperFactory.cpp (1) The GObject DOM build should be split out into a new automake intermediate library separate from libwebkit_1_0_la and libWebCore_la and (2) the gdom public headers should be installed under a new prefix in the destination directory eg.: libgdom_ladir = $(prefix)/include/webkit-1.0/gdom libgdom_la_HEADERS = \ $(gdomgtk_h_api) \ WebKit/gtk/webkit/gdom.h # Convenience libraries noinst_LTLIBRARIES = \ libJavaScriptCore.la \ libWebCore.la \ libgdom.la The rationale for this is twofold: (1) It'll be helpful for both WebKit hackers and application developers to immediately see the separation between the hand-written core WebKit/GTK+ API (2) Other WebKit ports using GObject but not GTK+ or the WebKit/GTK+ API layer will still be able to share the same DOM binding to some extent. Private* C++ sources and headers: As far as I can tell, the PrivateGdom*.cpp generated files are redundant. The code generated into PrivateGdomElement.cpp could just as well go into GdomElement.cpp for example, right? The PrivateGdom*.h files also look fairly empty right now, but I imagine that private headers for each DOM class could still end up being useful, depending on how you go about merging the Private*.cpp implementations. Getting rid of the Private*.cpp sources will help reduce compile time and reduce the size of the lists of generated files in the build system. Do let me know if I've got something wrong here -- there may be a good rationale for these privates that I've missed. Filenames: This one is open to discussion, but I think the best naming convention for the generated header files (and probably also the generated .cpp implementations) is 'gdom-html-menu-element.h' instead of 'GdomHTMLMenuElement.h'. You can use the same algorithm used in the code generator to generate these filenames. The hyphens deviate from our existing headers a little but they're important for clarity when it comes to the kind of type names you get in the DOM. I don't think you need to change this yet since it'll be even more of a pain to maintain the build system while working on the patch, but we'll need to remember to re-visit this point later. Exception codes: The ExceptionCodes are currently discarded. At some point we'll want to store these error codes (like the JS bindings do with setDOMException()) and allow for retreival following the call. Again, this isn't a top priority and can be dealt with when the other issues are fixed. String management: First off, you need to use WebCore::String::fromUTF8() rather than WebCore::String() any place a const gchar* is passed in since GObject strings deal in UTF-8. There is a major problem with const gchar* as a return value. As far as I can tell, GStringConvert() returns g_strdup()'ed strings which need to be manually g_free()'ed by the caller. First of all, this code shouldn't be duplicated in every generated file, but moreover, we try to return strings that the caller doesn't have to free manually and gdom breaks that convention. Potential ways of solving this: (*) Keep around a single CString and replace it each time a function returns a string. Not good because after two subsequent DOM function calls returning strings, the first will become invalid. (*) Simple GC. Keep around the CStrings or references to the g_strdup() result and free them in an idle handler. (*) AtomicStrings are probably easier to cache than Strings, so they could have a more efficient special-case? The good news is that most strings are accessed via GObject properties rather than const gchar* returns, of which there are only 33: $ grep -h -A1 'WEBKIT_API const gchar \*' DerivedSources/Gdom*.h | egrep -v -- '--|WEBKIT_API' gdom_character_data_substring_data (GdomCharacterData *thiz, gulong offset, gulong length); gdom_css_primitive_value_get_string_value (GdomCSSPrimitiveValue *thiz); gdom_css_style_declaration_get_property_value (GdomCSSStyleDeclaration *thiz, const gchar *property_name); gdom_css_style_declaration_remove_property (GdomCSSStyleDeclaration *thiz, const gchar *property_name); gdom_css_style_declaration_get_property_priority (GdomCSSStyleDeclaration *thiz, const gchar *property_name); gdom_css_style_declaration_item (GdomCSSStyleDeclaration *thiz, gulong index); gdom_css_style_declaration_get_property_shorthand (GdomCSSStyleDeclaration *thiz, const gchar *property_name); gdom_css_variables_declaration_get_variable_value (GdomCSSVariablesDeclaration *thiz, const gchar *variable_name); gdom_css_variables_declaration_remove_variable (GdomCSSVariablesDeclaration *thiz, const gchar *variable_name); gdom_css_variables_declaration_item (GdomCSSVariablesDeclaration *thiz, gulong index); gdom_document_query_command_value (GdomDocument *thiz, const gchar *command); gdom_dom_application_cache_item (GdomDOMApplicationCache *thiz, gulong index); gdom_dom_core_exception_to_string (GdomDOMCoreException *thiz); gdom_dom_selection_to_string (GdomDOMSelection *thiz); gdom_dom_window_prompt (GdomDOMWindow *thiz, const gchar *message, const gchar *default_value); gdom_element_get_attribute (GdomElement *thiz, const gchar *name); gdom_element_get_attribute_ns (GdomElement *thiz, const gchar *namespace_uri, const gchar *local_name); gdom_event_exception_to_string (GdomEventException *thiz); gdom_html_anchor_element_to_string (GdomHTMLAnchorElement *thiz); gdom_html_canvas_element_to_data_url (GdomHTMLCanvasElement *thiz, const gchar *type); gdom_media_list_item (GdomMediaList *thiz, gulong index); gdom_node_lookup_prefix (GdomNode *thiz, const gchar *namespace_uri); gdom_node_lookup_namespace_uri (GdomNode *thiz, const gchar *prefix); gdom_range_exception_to_string (GdomRangeException *thiz); gdom_range_to_string (GdomRange *thiz); gdom_storage_key (GdomStorage *thiz, gulong index); gdom_storage_get_item (GdomStorage *thiz, const gchar *key); gdom_xml_http_request_exception_to_string (GdomXMLHttpRequestException *thiz); gdom_xml_http_request_get_all_response_headers (GdomXMLHttpRequest *thiz); gdom_xml_http_request_get_response_header (GdomXMLHttpRequest *thiz, const gchar *header); gdom_xml_serializer_serialize_to_string (GdomXMLSerializer *thiz, GdomNode *node); gdom_x_path_exception_to_string (GdomXPathException *thiz); gdom_x_path_ns_resolver_lookup_namespace_uri (GdomXPathNSResolver *thiz, const gchar *prefix); If we can't figure out a smart approach for string management, we can use the dumb GC approach for now and open a new bug for UTF-8 DOM string optimisations.

Alp Toker

Comment 29 2008-09-13 04:55:48 PDT

Also, the GDOM* C++ classes (and PrivateInt*.h) don't seem to serve much of a purpose at first glance unless I missed something. If you look at WebCore/bindings/objc/DOM.mm you can see that the ObjC binding happily creates platform objects directly without this indirection, and it should be possible to construct the GObject wrappers directly in a similar fashion.

Luke Kenneth Casson Leighton

Comment 30 2008-09-13 08:36:58 PDT

alp, hi, great! thanks for the comments - much appreciated. lots to be getting on with :) ok - first things: little bit of explanation. the Private*, PrivateInt* and Gdom*props.h headers were created to avoid major, major headaches in the generation and use of #includes. a number of times i ended up with circular #include dependencies, and the only way to break them was to split the header files. one of the key purposes of splitting the headers is to keep the internal class implementations separate from their use (e.g. in webkitwebview.cpp). so, although things are declared as a typedef GdomDOMdocuement for example, they're never actually dereferenced - hence the Private header files contain the actual structs. i also liked the idea of keeping the stuff that was stored _in_ the Gobject separate as well (the classes that all derive down to GdomDOMObject) - hence the private cpp file. but... yes... you're right: it's a superfluous requirement - more of a style thing. but the header files: absolutely not. it was hell getting those right :) regarding the trailing white space: yep, more than likely. many of the hand-edited files started life off as auto-generated and modified or borrowed :) regarding the strings thing: yep :) i just... guessed at the best function, relied on the compiler to tell me where i was going wrong. if there'd been any comments in the code "don't use this, use this" i'd have gone "oh, look, i'm supposed to use this" ... :) decamelise: yehh, i just cut/paste your original work, alp :) i fell afoul of the h2defs.py codegen for pywebkitgtk, too, over the x_path_blah things. urgh. GStringConvert originally began life as a macro, and, after running into KURL and other strings, quickly turned into a class. not having created _any_ files in WebCore/bindings/gdom at the time, i avoided it.... that's my excuse :) the string GC thing sounds... _really_ messy. samba avoids the issue entirely by having talloc - a system of memory allocation which remains permanent-per-context. when you destroy the group of objects with which the talloc context is associated, you know it's safe to destroy the talloc context. apache has something similar, with "pools". in both cases, the only "free()ing" you do is at the global level, when you free the entire talloc (or the entire pool). the only reason i returned the strings at all as g_alloc()ed was because i anticipated that there might be conventions for dealing with strings in glib/gobjects - "caller frees return results". [certainly in DCE/RPC applications, which is the mother-of-all RPC systems, the convention is "caller frees return results". it _has_ to be that way, because of the client-server divide. then if you remove the RPC middle layer, and link the client-bit-of-code to the server-bit-of-code in one monolithic app, the application still behaves correctly, memory-wise.] in python - specifically the codegen stuff - the .defs file can specify "caller owns result" - something like that - or "callee owns result = false". indicating that code must be auto-generated to free up the return result when it's no longer needed. now, if there's a safe way to return a pointer to e.g. the underlying unicode string, rather than make a copy of it as utf-8, then heck, i'll do that! glib does support unicode strings (er... he said...) pffh, i've no idea what i'm talking about - i'm neither a webkit not a glib expert :) the separate library-space thing i _really_ like - for exactly the reasons you say: namely that the gdom bindings really don't have anything to do with gtk. which is great. to make it abundantly clear, i'd love to see pywebkitqt make use of the glib bindings (yes i'm serious!) i've been toying with the idea of _not_ adding to pywebkitgtk but instead creating pywebkitgdom. aside from anything, pywebkitgtk is really small, and it's a bit cheeky to turn it from a 50k to a 300k monster! so, a pywebkitqt4 could easily import pywebkitgdom. the interface between the two would be a bit iffy, though, even if it was in only two or three places (like it is in webkitwebview.cpp) hmmm... more later.

Luke Kenneth Casson Leighton

Comment 31 2008-09-13 08:57:33 PDT

> Also, the GDOM* C++ classes (and PrivateInt*.h) don't seem > to serve much of a purpose at first glance unless I missed something. > If you look at WebCore/bindings/objc/DOM.mm you can see that the ObjC binding > happily creates platform objects directly without this indirection, and it > should be possible to construct the GObject wrappers directly in a similar > fashion. alp, imagine i'm sitting in front of you, so you can see how wide my eyes are, with this big comic 1000-yard stare on my face like the top of my head is about to come off and bits of brain go into the sky and rain down over a 50 metre radius. the speed and intensity with which i got this stuff going was scarily quick. much of the decisions were made... how-to-say... on auto-pilot. to do the GdomDOMObject stuff i cut/paste large sections of JS* code, and followed whatever styling - from both the ObjC _and_ the JS stuff - worked best. the Gdom* classes i had to create, following the exact same reasoning from the JS classes. it was a looong ten days ago.... oh, christ, i remember now. it's coming back... yes. the hash-map thing. references. the Gdom* classes store a ref. this is absolutely essential. and, you need a virtual base class in the lowest-level thing - GdomDOMObject - to be able to call in to find out the GOBJECT_TYPE. otherwise, you end up creating the wrong type of "wrapper". that's the whole point of the GDOM*ElementFactory thing - and the whole point of the JS*ElementFactory - exactly the same issue. what happens otherwise is that if you call e.g. gdom_create_text_node() and add it to the DOM with gdom_node_add_child(parent, textnode), and you then get it back with gdom_document_get_element_by_id(), if you _don't_ have the DOMObjectCache that GdomDOMObject refers to, whilst gdom_create_text_node() creates a GDOM_TEXT_NODE, gdom_document_get_element_by_id() returns .... a GDOM_NODE!!! because that's the return result - a base class - that gdom_document_get_element_by_id() returns! which of course is completely unacceptable - and, worse, you end up with _two_ different types of GObjects - one a GDOM_NODE and another a GDOM_TEXT_NODE - pointing to exactly the same underlying c++ object! so, i had to cut/paste the JS*ElementFactory code, pretty much verbatim. so, the hash map avoids the problem of returning different glib objects that represent the same c++ object; the pure virtual function GDOMObject::get_gobj_type() makes sure that you construct the _correct_ type of glib object even when you're down in things like gdom_document_get_element_by_id(); the toGDOM functions actually do the heavy-lifting in that regard (copying cut/paste the style of all the toJS functions); it's all utterly hair-raising and i'm now going downstairs to watch some mindless tv to let my brain cool down :)

Luke Kenneth Casson Leighton

Comment 32 2008-09-14 03:15:27 PDT

> Core API changes: > webkitevent.h/WebKitEvent: We try to avoid generic type names in the core > WebKit/GTK+ public API since 'WebKit.Event' will be ambiguous when 'Gdk.Event' > is imported in many OO language bindings. So this could become either > WebKitWebEvent, could go into the Gdom namespace or even somehow be merged with > GdomEvent (I haven't investigated enough to see if this last suggestion would > make sense though). WebKitEvent - or WebKitWebEvent as it's now known - is a slight hack, being on the boundary between gtk and glib. ideally, WebKitWebEvent should not exist, because it is a manual .... err.... actually, i can't find evidence of it being used anywhere :) i think i already replaced it with GdomEvent.... so... webkitevent.h and webkitwebevent.h die. we need webkitwebevent.cpp though: it's the interface-boundary to creating the three (currently three) types of events - including xmlhttprequest event notification, required for async ajax.

Luke Kenneth Casson Leighton

Comment 33 2008-09-14 04:44:00 PDT

Created attachment 23409 [details] updated fixing review requests removed spaces removed webkitevent.h removed webkit_web_event* from webkitevent.cpp renamed webkitevent.cpp to webkitwebevent.cpp removed tabs

Luke Kenneth Casson Leighton

Comment 34 2008-09-14 05:07:03 PDT

> Special-cases for lower_case_conversion: > decamelize() is great, but sometimes we'll want to special-case certain > character sequences to avoid awkward function names. Right now we get > gdom_x_path_exception_to_string() but what we really want is > gdom_xpath_exception_to_string(). Some cases I noticed: XPath, WebKit, > gdom_htmlbr_element_get_type, gdom_htmld_list_element_get_type alp, um... i had to mention it, eventually, but... me and perl don't get along too well - we're not best of friends. me and regular expressions _really_ don't get along :) ... can i possibly leave this one to you? if you give me _one_ example i can do the rest. i do need a matching camelize() too because i think sometimes i run the decamelize backwards. l.

Luke Kenneth Casson Leighton

Comment 35 2008-09-14 05:45:21 PDT

> _init functions vs. constructors: > There are some generated functions like gdom_wheel_event_init_wheel_event(). > These should probably be mapped to GObject constructors, ie. > gdom_wheel_event_new(). i no unnerstaan. ok - explanation time. the way that the code is set up, there is no way for external code (users of the library) to call gdom_xxxxxx_xxxx_new(). none. not a single one. this is thoroughly deliberate. the only entry point is through webkitweb*.cpp. yes, i realise this will have to change (in order to support webkit-glib as an "independent" library). ... quick hunt through source code to find if i end up making a GdomFrame... no. huh. ok... i think... the sensible thing to do would be to create a manual GdomFrame, which _does_ have a gdom_frame_new() constructor etc. which takes in the Frame, etc. looking closely, it'd be virtually identical to webkitwebframe.cpp - except with no mention of "Gtk" anywhere. anyway. there's zero public access to the gdom_xxx_new() functions. not even webkitwebframe.cpp or webkitwebview.cpp or even the new event handling webkitwebevent.cpp call them: they all use "toGDOM()" which is the equivalent of "toJS". in fact, now i remember: i *entirely* removed the gdom_xxxx_new() functions. the *only* place where gdom gobjects get created is in WebCore/bindings/gdom/GDOMBinding.cpp create_gdom_object(). note the use of the virtual function, GDOMObject::get_gobj_type() the only way to get the that create_gdom_object() function is via a toGDOM() function - of which there are... 300 or so, 297 of which are auto-generated. create_gdom_object is even _static_ to GDOMBinding.cpp. in this way, it's absolutely cast-iron guaranteed that the glib objects will be "managed" (by the hash-map); that a c++ object which has already had a glib wrapper created around it gets the same glib object back, even if a glib object of a different type (base class) is being requested; that all the ref()s are handled correctly. if i were to let people do gdom_xxx_new() calling, those guarantees would no longer be in place. additionally, once you have that initial "Frame", there's no _need_ to go calling any gdom_xxx_new() functions, because of all the getter functions and the creater functions - and the constructors in the DOM model and the IDL files. so, the glib bindings would do well to have a manually-coded GdomFrame, which WebKitWebView either derives from or has as a member, thus making it even clearer that the glib gdom bindings are independent of gtk; providing that single-entry choke point into the gdom functions n stuff. so - although it would be a good idea to map gdom_wheel_event_init_wheel_event to gdom_wheel_event_new() - there doesn't actually exist a gdom_wheel_event_new() to map _to_ :) ... not that i entirely understand what you mean by "map", so i apologise if this explanation is particularly long and pointless, but i hope it helps at least explain some of the very-quickly-made design decisions.

Luke Kenneth Casson Leighton

Comment 36 2008-09-14 06:10:43 PDT

> First off, you need to use WebCore::String::fromUTF8() rather than > WebCore::String() done. > webkitprivate.h defines WEBKIT_PARAM_READABLE and WEBKIT_PARAM_READWRITE > replacements for G_PARAM_READABLE and G_PARAM_READWRITE which tell GObject that > it doesn't need to copy the input strings to g_param_spec(). It's probably > worth reusing this (or copying equivalents into gdomprivate.h or similar). done.

Luke Kenneth Casson Leighton

Comment 37 2008-09-14 11:06:36 PDT

const gchar strings. i asked on gtk-devel list and got a reply which explains, so now i know a little bit what you're referring to. "const gchar string" means "thou shalt not free the return result". all other strings, the convention is defined by the library itself, but it's usually "caller frees return result". i'd much prefer that the convention for glib be "caller frees return result". even in the case of const properties, by stripping off the "const" on the return result. that way, what the e.g. pywebkitgtk can be told is "all strings into your domain, you're responsible for free()ing".

Luke Kenneth Casson Leighton

Comment 38 2008-09-14 13:20:27 PDT

pyjd.py:378: Warning: g_param_spec_internal: assertion `!(flags & G_PARAM_STATIC_NAME) || is_canonical (name)' failed using WEBKIT_PARAM_READABLE and WEBKIT_PARAM_READWRITE causes a segfault in g_param_specstring() when g_object_new() is called (!) trying just G_PARAM_READABLE....

Luke Kenneth Casson Leighton

Comment 39 2008-09-14 13:34:14 PDT

i've screwed something up :) tomorrow's debugging session will involve tracking down a segfault that ends in g_param_spec_string() of all places.

Christian Persch (GNOME) (away; not reading bugmail)

Comment 40 2008-09-14 14:17:43 PDT

(In reply to comment #38) > pyjd.py:378: Warning: g_param_spec_internal: assertion `!(flags & > G_PARAM_STATIC_NAME) || is_canonical (name)' failed > > using WEBKIT_PARAM_READABLE and WEBKIT_PARAM_READWRITE causes a segfault in > g_param_specstring() when g_object_new() is called (!) That means that the property name was not canonical: * Parameter names need to start with a letter (a-z or A-Z). Subsequent * characters can be letters, numbers or a '-'. * All other characters are replaced by a '-' during construction. * The result of this replacement is called the canonical name of the * parameter.

Luke Kenneth Casson Leighton

Comment 41 2008-09-15 03:38:29 PDT

Comment on attachment 23409 [details] updated fixing review requests take off "review" status for now, have to rework things fix some segfaults.

Luke Kenneth Casson Leighton

Comment 42 2008-09-15 06:34:08 PDT

Created attachment 23436 [details] more review fixing * created libgdom.la * created WebKit/gtk/gdom directory * removed const around gchar* (to give pywebkitgtk a change to free the string) * resolved segfault (somehow....) * created WebKit/gtk/gdom/GStringConvert.h

Luke Kenneth Casson Leighton

Comment 43 2008-09-15 07:35:41 PDT

Created attachment 23440 [details] merged PrivateGdom*.cpp into Gdom*.cpp works fine. no real need. header files separate is the key priority.

Luke Kenneth Casson Leighton

Comment 44 2008-09-15 08:21:25 PDT

ok. chasing through python-gobject, a string property in the "getter" functions is passed to "PyString_AsString()" - not "PyString_FromString()". PyString_AsString "takes over" the string data. PyString_FromString makes a copy. in other words, the convention is "caller responsible for freeing". in other words, the last thing i want to do is to make the gdom bindings return "unmodifiable" copies of strings for which the library itself is responsible. removing "const gchar*" and making it "gchar*", and then specifying " (caller-owns-return #t)" makes sure that pywebkitgtk takes responsibility for the memory. hmm, looks like codegen.py could do with an optimisation by using AsString and then _not_ free()ing the string it's been passed, but that's another story. talking to people on the gtk-devel-mailing list: http://mail.gnome.org/archives/gtk-devel-list/2008-September/msg00080.html one person says, basically, that GC is really fraught with difficulties. overall, i get the impression that a simple convention "caller responsible for freeing" not only makes everybody's lives easier, but is also expected. certainly python-gobject and pygtk's codegen that looks like it's the case.

Luke Kenneth Casson Leighton

Comment 45 2008-09-15 11:04:37 PDT

alp, hi, i'm going slightly off my head, revisiting this stuff, strings-wise, but i _think_ i'm in the clear on properties. g_value_from_string() returns the string contained in a GValue. const gchar*. not copied. that gets passed (now) to WebCore::CString::fromUTF8(). that accepts const char*, so _it's_ happy. GdomAttr.cpp setValue() accepts a CString so it's happy, too. GValue is taken care of by gobject, so it's all good. setting: err.... i think i messed up, here: i think i should be using g_value_take_string()....

Mark Rowe (bdash)

Comment 46 2008-09-16 09:47:08 PDT

Can you please name the generated files with a format that matches our coding style? "GdomBarInfo.h" doesn't match our naming conventions, and should probably be GDOMBarInfo.h. If these files are to be part of the WebKit GTK API then they should match the GTK naming convention, which I believe does not use upper-case letters at all. Alp may be able to provide suggestions about what the right naming scheme is here. The changes in FrameLoaderClientGtk.cpp look bogus. Why are they in this patch? Why does GDOMObject.h have a commented out 'namespace WebCore'? Why does it have a function named get_gobj_type which doesn't match our naming conventions? The includes in webkitwebframe.cpp should be sorted per our style conventions. They also shouldn't have the "gdom/" prefix. The private header files should be have Private as a suffix to match the convention used elsewhere in the project (PrivateGdomDOMWindow.h -> GDOMWindowPrivate.h). It's not clear to me why some of the files have "Int" in their name. Is that short for "Internal"? If so, the file should use that as a suffix in place of Private, such as GDOMWindowInternal.h. There are commented-out printf's in webkitwebevent.cpp which shouldn't be there. PrivateIntGdomEventTargetNode.h lacks a license header, and the Apple Inc. copyright line lacks the "All rights reserved." note that should be present. The file also uses strange formatting for the include guard. Please see existing code for an example of the style that should be used. The code in GStringConvert.h lacks a license header. I'm not sure what the point of the GStringConvert class is. It seems like it could easily be implemented using a simple overloaded function rather than the strange class + macro combination. The "extern C" around a C++ class doesn't make a lot of sense either. The header includes in this file also need sorted. Do the values for FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT ever differ? If not, is there any point in having both? GDOMHTMLElementWrapperFactory.cpp says that "THIS FILE IS DERIVED FROM AN AUTOMATICALLY GENERATED FILE." what file is it derived from, and why is it being checked in if it is a generated file? GDOMBinding.cpp has some FIXME's, TODO's and a lot of commented-out code that should be cleaned up before this can be landed. Some of the IDL file changes do not look correct. I would think that the GObject bindings would want to match the behaviour of the Obj-C DOM bindings rather than JS in the cases that they differ. Many of these instances are due to behavioral peculiarities of JS, especially attributes such as ConvertNullToNullString and toString functions. All in all, this is looking like a good start, but it needs a lot more polish and refinement before it can be landed. I've primarily commented on style issues. Hopefully Sam will be able to take a look at the implementation details once the patch is cleaned up and easier to follow, and Alp and other GTK developers can provide feedback on the new API.

Mark Rowe (bdash)

Comment 47 2008-09-16 09:47:21 PDT

Comment on attachment 23440 [details] merged PrivateGdom*.cpp into Gdom*.cpp Marking as r- based on my comments.

Luke Kenneth Casson Leighton

Comment 48 2008-09-16 13:02:37 PDT

> Can you please name the generated files with a format that matches > our coding style? "GdomBarInfo.h" doesn't match our naming conventions, > and should probably be GDOMBarInfo.h. someone make a firm decision, tell me what to do, i'll go with it. alp recommended gdom-xxx-xxx-xxx.h > If these files are to be part of the WebKit GTK API they're not part of the webkit gtk api. they're entirely independent of the GTK api. they _happen_ to be _used_ by the GTK api, as a first example usage - and i am investigating how the QT api should use them, too (pending someone writing a qt bindings). they're "glib" bindings, not "gtk" bindings. creation of a Glib object around both WebCore::Frame and WebCore::Page will allow their use in other widget sets. > Alp may be able to provide suggestions about what > the right naming scheme is here. yep - he did - but they break the webkit coding conventions. > The changes in FrameLoaderClientGtk.cpp look bogus. without that simple fix, any frames opened up in any page will instantly cause a segfault. > Why are they in this patch? because i need to get something working and useable, the patch is 7,000 lines long, i'm too low on disk space to have several copies of webkit checked out using git to manage several revisions of the patch - one to send to you and one to have something that actually "works". it's the "working solution". nasty as hell, but it works. if someone can fix #20403 i won't need that nasty fix. > Why does GDOMObject.h have a commented out 'namespace WebCore'? i believed it necessary at some point in the development cycle, and was oscillating between it being there and not. it's gone. > Why does it have a function named get_gobj_type which > doesn't match our naming conventions? pick a name - any name, i'll use it. > The includes in webkitwebframe.cpp should be sorted per our style conventions. done. i think. > They also shouldn't have the "gdom/" prefix. yeahh, i was going to convert to <gdom/NNNNN.h> to make it unequivocably clear that the glib bindings have absolutely nothing to do with being part of the gtk port. > The private header files should be have Private as a suffix to match the convention used elsewhere in the project (PrivateGdomDOMWindow.h -> GDOMWindowPrivate.h). It's not clear to me why some of the files have "Int" in their name. Is that short for "Internal"? yep. > If so, the file should use that as a suffix in place of Private, such as GDOMWindowInternal.h. ok. ... ahhh ... wait - i think that interferes with the pattern matching in WebCore/GNUMakefile.am - specifically: DerivedSources/gdom/PrivateGdom%.h: DerivedSources/gdom/Gdom%.cpp; etc. if someone can come up with a suitable pattern-match that works, without make thinking that the "*Internal*" files have make rules, and can come up with a suitable match also for the "*Private*.h" rules, then the names of the files can change. > There are commented-out printf's in webkitwebevent.cpp which shouldn't be > there. gone. > PrivateIntGdomEventTargetNode.h lacks a license header, whoops, sorted. > and the Apple Inc. copyright line lacks the "All rights reserved." note that should be present. then that means that somewhere there is another file missing it, from which the text was cut and paste. in amongst two weeks of very intense programming, i could not say which one it is. > The file also uses strange formatting for the include guard. Please see > existing code for an example of the style that should be used. it's auto-generated, it's perl, and it's easier to append "__INT_" than it is to write yet another perl function which makes the perl code - already unreadable - yet more complex. if you _really_ want me to make the auto-generator more complex, please state so clearly and i will be happy to do it. > The code in GStringConvert.h lacks a license header. added. > I'm not sure what the > point of the GStringConvert class is. It seems like it could easily be > implemented using a simple overloaded function rather than the strange class + > macro combination. huh. so it could :) > The "extern C" around a C++ class doesn't make a lot of sense either. yep - and it's not needed, either. at some point, there was a bit of a mess involving extern "C"s... :) > The header includes in this file also need sorted. done > Do the values for FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT ever differ? most definitely they do. > If not, is there any point in having both? most definitely there is. 1) LANGUAGE_GOBJECT=1 look at which functions are "custom"; look at which functions in the idls are defined for objc and which for 2) SVG. see #20586. i'm _not_ adding svg supoprt until this patch is accepted. it's far too much additional work. > GDOMHTMLElementWrapperFactory.cpp says that "THIS FILE IS DERIVED FROM AN > AUTOMATICALLY GENERATED FILE." what file is it derived from, and why is it > being checked in if it is a generated file? because it's not an auto-generated file. if someone else - i.e. not me - would like to write some perl code or other code which auto-generates that file, they are welcome to do it. i'm not a perl coder, but i'm very good at cut/paste from examples of perl code. > GDOMBinding.cpp has some FIXME's, TODO's and a > lot of commented-out code that > should be cleaned up before this can be landed. i'm leaving the TODOs in for future reference, for another patch, for additional functionality e.g. SVG. i _can_ remove the remainder of the FIXMEs and TODOs if you like but that would mean that future developers will find it more difficult to track down issues. > Some of the IDL file changes do not look correct. > I would think that the GObject bindings would want to match > the behaviour of the Obj-C DOM bindings > rather than JS in the cases that they differ. > Many of these instances are due > to behavioral peculiarities of JS, especially attributes such as > ConvertNullToNullString and toString functions. i'm.... i'll be absolutely brutally honest, here: i'm really not ... how do i put this best... imagine that there is a good way to say "no, i'm not going to make any further changes, additions or enhancements or even compliance to standards" without causing offense, and then taking that as being said - repeatedly and clearly - throughout the next few sentences. i've reached my limit - unpaid work-wise - on amount of time and effort to spend on adding extra functionality. if you can find some money, somewhere, i'll do the additional work. otherwise, the only circumstances under which i will make additional changes is if there is a serious bug. memory leak, simple coding standards changes, style conventions etc - i've no problem with that. i'm missing the use of "Location" property setting (because it's a custom function) and i'm not even adding _that_, and i need it in pyjamas-desktop, and i'm _still_ not going to add it, until after this patch goes through. a 7,500 line patch is enough. i've done free software projects which resulted in nearly 150,000 lines of additional code being added - three years work, entirely wasted (because of people's egos). i'm not doing that again. so - no more changes. what's there "works". if it's not javascript standards compliant (because i #ifdef LANGUAGE_GOBJECT'd in a function called open(CString) when LANGUAGE_JAVASCRIPT does open(WebCore::class) - tough. it works, it avoided many issues which can be fixed... _later_. not now. > All in all, this is looking like a good start, thanks. > but it needs a lot more polish > and refinement before it can be landed. that's ok. extra functionality, changes to various workarounds which can be planned for later patches - not ok. sorry. > I've primarily commented on style issues. very helpful, thank you. i believe i've dealt with most of them as i've written this, and left > Hopefully Sam will be able to take a look at the > implementation details once the patch is cleaned up > and easier to follow, and Alp and other > GTK developers can provide feedback on the new API. yaay. well, unfortunately, the auto-generator is always going to be a bit of a mess: i'm not a perl programmer, as i mentioned above, but i'm extremely good at cut/paste and "getting results" through extremely rapid development cycles. i'm sorry about the extra functionality thing. i'm working on this for a personal project - unfunded - and am under extreme financial pressure. many of the decisions made can be revisited and refined - but if it came to a choice between "significant extra functionality needed to land the patch" and "walking away", i walk away. there's enough extra work on the list already: i'm holding back _several_ bug reports and features until it's landed, simply because there's so much involved, i don't want to riddle the webkit database with stuff that could change. landing this patch - with functionality "as-is" - means that there's a stake in the ground to move forward from.

Luke Kenneth Casson Leighton

Comment 49 2008-09-16 13:33:32 PDT

"WebCore/html/HTMLOptionElement.idl" #if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) attribute [ConvertNullToNullString] DOMString text setter raises(DOMException); #else readonly attribute DOMString text; #endif in the gobject bindings, i'm ignoring entirely the "ConvertNullToNullString", and making use of the fact that the #ifdef makes the attribute writeable rather than read-only. some of the pyjamas-desktop code required write access to the text (equivalent to setting "innerHTML"). at _some point in the future_ - after the patch has been landed, revisiting the "ConvertNullToNullString" and other idl modifiers, should be examined. ... but _not_ right now. what's there "works" - pyjamas-desktop, and pywebkitgtk "work". there's no need to fix what isn't broken.

Luke Kenneth Casson Leighton

Comment 50 2008-09-16 13:37:08 PDT

--- WebCore/html/HTMLEmbedElement.idl (revision 36459) +++ WebCore/html/HTMLEmbedElement.idl (working copy) @@ -30,7 +30,7 @@ ImplementationUUID=93e0407a-8380-4ff0-978d-f773f2dee6a3 ] HTMLEmbedElement : HTMLElement { attribute [ConvertNullToNullString] DOMString align; -#if defined(LANGUAGE_JAVASCRIPT) +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) attribute [ConvertNullToNullString] DOMString height; #else attribute [ConvertFromString] long height; @@ -38,7 +38,7 @@ attribute [ConvertNullToNullString] DOMString name; attribute [ConvertNullToNullString] DOMString src; attribute [ConvertNullToNullString] DOMString type; -#if defined(LANGUAGE_JAVASCRIPT) +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) attribute [ConvertNullToNullString] DOMString width; #else attribute [ConvertFromString] long width; exact same functionality as javascript is required. an int width and an int height is of absolutely no use. pyjamas-desktop needs to be able to set width and height to what _javascript_ does - not objectiveC. i.e. "100%". "10em". "20px". the integer-only parameters are no use to anyone wishing to maintain line-for-line javascript equivalent functionality, which is what pyjamas-desktop is about: ripping out the javascript and replacing it with exact-equivalent code, written in python instead of javascript.

Luke Kenneth Casson Leighton

Comment 51 2008-09-16 13:42:27 PDT

--- WebCore/xml/XMLHttpRequest.idl (revision 36459) +++ WebCore/xml/XMLHttpRequest.idl (working copy) @@ -62,9 +62,13 @@ raises(DOMException); // void send(); - // void send(in DOMString data); +#if defined(LANGUAGE_GOBJECT) + void send(in DOMString data) + raises(DOMException); +#else [Custom] void send(in Document data) raises(DOMException); +#endif this one was a pain. i went to considerable effort to try and use Document, added glib bindings around TextDocument, other documents, HTMLDocument, and tried _really_ hard to create a Document from scratch using the glib bindings. in the end, i gave up - i believe it's because i haven't yet added "gobject" property setting (i have strings, ints, floats etc. just not glib objects). so i went for the simplest possible option - pass in a text "string". so _in the future_, this needs to be revisited. but _not now_.

Luke Kenneth Casson Leighton

Comment 52 2008-09-16 13:47:02 PDT

--- WebCore/page/DOMWindow.idl (revision 36459) +++ WebCore/page/DOMWindow.idl (working copy) @@ -155,7 +155,7 @@ [DoNotCheckDomainSecurity, Custom] void postMessage(in DOMString message, in DOMString targetOrigin) raises(DOMException); -#if defined(LANGUAGE_JAVASCRIPT) +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) // Global constructors attribute StyleSheetConstructor StyleSheet; attribute CSSStyleSheetConstructor CSSStyleSheet; i've added this in as a reminder that, at some point _in the future_, the gobject auto-generator code will need to auto-generate "constructors". i believe this was part of the problem i had in doing creation of a document - not having some of these functions. although it will be straightforward to add constructors, i'm not doing it for this patch.

Luke Kenneth Casson Leighton

Comment 53 2008-09-16 14:19:53 PDT

Created attachment 23488 [details] updated for many of mrowe's comments mark, hi, attached - updated to reflect the coding standards and many other issues you kindly raised.

Alp Toker

Comment 54 2008-09-17 14:09:35 PDT

So, I'm going to propose a strategy to avoid burning out lkck and getting this feature landed as rapidly as possible. lkck, what would you think about modifying the patch so it doesn't touch the WebKit public API layer at all? Those changes can be left as a patch in bug #16686 and landed when we're nearer to having a stable DOM binding. This would mean moving functions like webkit_web_frame_get_dom_document() into libgdom.la for now (or maybe making a temporary helper class like WebKitDomHelper in libgdom.la, dunno). Part of the problem is that as soon as this shows up in the main API, we'll have to start freezing and won't have much room for changes.

Luke Kenneth Casson Leighton

Comment 55 2008-09-17 14:28:05 PDT

Created attachment 23508 [details] massively (oversimplified, unfortunately) reduced patch ok - after talking to mark, given that the target functionality requires a 250k patch, here is a _reduced_ patch (80k) which provides no actual useable functionality but provides "a start". the only functionality added is "Node" - GdomNode. to ensure that memory corruption, memory leaks, lost ptrRefs and thus segfaults do not occur, GdomDOMObject - and the methodology copied directly almost word-for-word cut-and-paste from JSBindings.cpp into GDOMBindings.cpp is absolutely essential, and cannot be "cut".

Luke Kenneth Casson Leighton

Comment 56 2008-09-18 04:29:00 PDT

alp - great idea. the only places where changes are made anyway is _three_ extra functions. three. not one thousand five hundred. three. 1) webkit_web_frame_get_xml_http_request 2) webkit_web_frame_get_dom_window 3) webkit_web_frame_get_dom_document that's it. everything else is entirely "additions" that have no impact, no consequence, no effect and no modification of or to the webkit gtk code in any way, shape or form. the entire code added - including those three functions - has no impact, no effect, no additions, modifications or enhancements _at all_ in any way, shape or form to the webkit "core". more later i have work to do.

Luke Kenneth Casson Leighton

Comment 57 2008-09-18 09:07:34 PDT

+WEBKIT_API gboolean +webkit_web_frame_add_event_listener(WebKitWebFrame* frame, + const gchar *name); 4 functions, not 3. that would go into GdomFrame, as well.

Luke Kenneth Casson Leighton

Comment 58 2008-09-18 09:10:40 PDT

Created attachment 23531 [details] remainder of patch bringing gdom patch up to full functionality thanks to git, and git branches, i can keep track of different revisions. here's the "remainder" of the patch which provides the full functionality. apply attachment-23508 first, then this one.

Luke Kenneth Casson Leighton

Comment 59 2008-09-18 13:42:48 PDT

Created attachment 23535 [details] updated massively-reduced functionality patch removed, as requested, #ifdef'd code. the #ifdef'd code and the associated comments is a reminder to put in absolutely critical and essential functionality. the removal of this #ifdef'd code has been replaced with a description outlining exactly why the functionality which has not been completed is utterly essential for correct operation of the bindings code. this replacement patch is functionally useless, providing nothing but "Node". there is no way to test it (through the gtk webkit port) because there is no "link" in to the webkit_web_*() gtk bindings. this replacement patch is provided, as requested, on the basis that it will make it easier to assess the code in stages.

Luke Kenneth Casson Leighton

Comment 60 2008-09-19 13:08:57 PDT

DerivedSources/gdom/gdom%.cpp: %.idl $(SCRIPTS_BINDINGS) $(WebCore)/bindings/scripts/CodeGeneratorGObject.pm best that can be done, given this, without having 300 (400 if you include SVG at some point) makefile rules, is: gdom-Attr.cpp. i can auto-generate the headers gdom-attr.h, gdom-attr-private.h. it's the matching against % that ....

Luke Kenneth Casson Leighton

Comment 61 2008-09-19 13:17:21 PDT

DerivedSources/gdom/gdom%.h: DerivedSources/gdom/gdom%.cpp; can't do the header files, either. libgdom_la_HEADERS = \ $(libgdom_h_api) \ $libgdom_h_api = DerivedSources/gdomAttr.h ..... DerivedSources/gdom/gdom%.h: DerivedSources/gdom/gdom%.cpp; DerivedSources/gdom/Gdom%.cpp: %.idl $(SCRIPTS_BINDINGS) $(WebCore)/bindings/scripts/CodeGeneratorGObject.pm $(PERL) -I$(WebCore)/bindings/scripts $(WebCore)/bindings/scripts/generate-bindings.pl --include $(WebCore)/dom --include $(WebCore)/html --include $(WebCore)/css --include $(WebCore)/page --include $(WebCore)/xml --include $(WebCore)/svg --outputDir "$(GENSOURCESGDOM)" --defines "$(FEATURE_DEFINES_GDOM)" --generator GObject $< so... unless someone could come up with a solution, or you're happy to rename all idl files from Attr.idl and BarInfo.idl to attr.idl and bar-info.idl, the names either have to stick GdomAttr.h, perhaps be gdom-Attr.h and gdom-BarInfo.h, or have a post-processing stage which, for the purposes of placing them into /usr/include/webkit-1.0/gdom, performs a rename at that time rather than a straight copy. oh - and a rename. i'll attach a text-converter which will be capable of performing the rename, post-processing the text to replace gdom/GdomAttr.h with gdom/gdom-attr.h written in python cos i like python and it took me 10 mins rather than 30 plus aggro in perl :)

Luke Kenneth Casson Leighton

Comment 62 2008-09-19 13:18:25 PDT

Created attachment 23579 [details] converts upper-case GdomXyzAbc to gdom-xyz-abc

Luke Kenneth Casson Leighton

Comment 63 2008-09-20 01:26:31 PDT

Comment on attachment 23535 [details] updated massively-reduced functionality patch removed review request, patch soon to be obsoleted

Luke Kenneth Casson Leighton

Comment 64 2008-09-25 12:02:48 PDT

Created attachment 23812 [details] last patch - end of current available time and resources this patch is what is currently working and fully functional, sufficient to be "useable" for many projects. there is no more "free" time available for me to work on this, any more. contracting or any other kind of payment will result in further work. at some point in the future i may choose to work on this, to meet my own needs and requirements: should that occur, i will ensure that, like as with this patch, that you receive what i have written.

Martín Soto

Comment 65 2008-10-16 09:36:37 PDT

Created attachment 24395 [details] DOM patch updated to version 37602 A few changes to make the patch work with recent SVN. What's preventing this patch from being landed? I would really appreciate someone to summarize the open issues. I may put some work into it in the following days, but it's hard for me to determine what must still be done.

Mark Rowe (bdash)

Comment 66 2008-10-16 10:33:16 PDT

(In reply to comment #65) > Created an attachment (id=24395) [edit] > DOM patch updated to version 37602 > > A few changes to make the patch work with recent SVN. > > What's preventing this patch from being landed? I would really appreciate > someone to summarize the open issues. I may put some work into it in the > following days, but it's hard for me to determine what must still be done. Please read back over the review comments I have left on a previous version of the patch. There are many issues which have not yet been addressed and which need to be addressed before this can be landed. In general though, this patch is trying to do far too much at once which makes it very hard to get right without going through many iterations, and it also makes it a lot of work to review. An initial cut at the bindings that supports a subset of the functionality would be much quicker to clean up and get into a usable state, and would make it simple for others to finish off the work in parallel.

Luke Kenneth Casson Leighton

Comment 67 2008-10-16 12:27:02 PDT

mark, hi, all of the issues you raised i have either completed, explained the roadblocks and/or reasoning why they have, will or cannot be completed, or raised further questions, so i - and others - are awaiting responses to those issues. the patch as it stands is ... how-to-say... "feature-complete". "self-consistent". "is useable for production-ready purposes". "is ready for release". so, _yes_ there's a lot of code ... but... if there's a lot of code - tough luck. it does the job, it's useable, and i'm disinclined - and have not yet received any incentive - to do additional work to produce what will effectively be non-functional and non-useful patches, just so that apple employees can get their heads round the work. you and others in apple are _paid_ to work on this - you therefore have all the time in the world to sit down and work on understanding it. issues such as _how_ the code is to be used - such as the interface - have _not_ been finalised, and discussions on how the code is to be used have not proceeded. alp raised the issue that the three functions which have been added to WebKitWebView are not really appropriate an interface, and i agree with him. alp suggested *leaving out* those three functions, and i have mentioned previously that i agree that that's a very good way forward. then, for anyone who does want to use this work, they can just add in a temporary patch of only a few lines of code, and they're off. so, again, we're awaiting responses to the issues. i did attempt a "partial approach". it consumed large amounts of my time and disrupted the maintenance of the "real" patch. so, if given a choice between whether you, and others at apple, should spend time and effort during well-paid working hours, to learn how this patch works, or whether i should be asked to "dumb down" what's been done into chunks of non-useful work, when i've got £25,000 of debt hanging over my head, i'll choose... apple employees doing their job and learning something new and exciting in the process! the approach that i recommend that you take, due to the size of the patch, is to accept it "as-is". once that has been done, then i will be _more_ than happy to raise bugreports and guide others and/or even do additional work to address the issues. by removing the (three) function that make it "operational", you will be *stopping* the casual developer from assuming that the API has been finalised, without hindering the interested developers from cleaning up the work. there is absolutely no reason why this decision should not be taken, and there are many many reasons why it _should_ be taken. not least is the simple fact that the sheer number of issues that need to be addressed are _far_ too many to keep discussing in one bugreport. it's simply unmanageable. so from a purely _practical_ perspective, accept the damn patch and let's get on and make some damn progress.

Sam Weinig

Comment 68 2008-10-16 13:19:57 PDT

(In reply to comment #67) > mark, hi, > > all of the issues you raised i have either completed, explained > the roadblocks and/or reasoning why they have, will or cannot > be completed, or raised further questions, > > so i - and others - are awaiting responses to those issues. What issues do you believe are outstanding? It is unclear. > > the patch as it stands is ... how-to-say... "feature-complete". > "self-consistent". "is useable for production-ready purposes". > "is ready for release". As Mark noted, the reviewers have deemed that the patch needs further work. For instance, there is commented and #ifdefed out code that needs to be addressed and the changes to the IDL files which are incorrect, both of which have been pointed out in previous reviews. > > so, _yes_ there's a lot of code ... but... if there's a lot > of code - tough luck. it does the job, it's useable, and i'm > disinclined - and have not yet received any incentive - to > do additional work to produce what will effectively be non-functional > and non-useful patches, just so that apple employees can get > their heads round the work. > > you and others in apple are _paid_ to work on this - you therefore > have all the time in the world to sit down and work on understanding > it. We understand what it does, it simply is not yet up to the standards of the WebKit project. We pride ourselves on our code quality and readability and thus code that simply passes the "functional" test is not necessarily sufficient for committing. Our processes for review help us keep this high standard so we follow them for all code added to the tree. > > issues such as _how_ the code is to be used - such as the interface - > have _not_ been finalised, and discussions on how the code is to > be used have not proceeded. alp raised the issue that the three > functions which have been added to WebKitWebView are not really > appropriate an interface, and i agree with him. > > alp suggested *leaving out* those three functions, and i have > mentioned previously that i agree that that's a very good way > forward. > > then, for anyone who does want to use this work, they can just > add in a temporary patch of only a few lines of code, and they're > off. Decisions about the API are not relevant to these review comments. > > so, again, we're awaiting responses to the issues. > > i did attempt a "partial approach". it consumed large amounts > of my time and disrupted the maintenance of the "real" patch. > > so, if given a choice between whether you, and others at apple, should > spend time and effort during well-paid working hours, to learn how > this patch works, or whether i should be asked to "dumb down" what's > been done into chunks of non-useful work, when i've got £25,000 of > debt hanging over my head, i'll choose... apple employees doing their > job and learning something new and exciting in the process! > > > the approach that i recommend that you take, due to the size of the > patch, is to accept it "as-is". once that has been done, then i will > be _more_ than happy to raise bugreports and guide others and/or even > do additional work to address the issues. This is not an option. The patch needs to be reviewed, as all patches are, before they can be landed. If you would like to expedite this process, you can take Marks advice and pare down the scope of this patch. > > by removing the (three) function that make it "operational", you > will be *stopping* the casual developer from assuming that the API > has been finalised, without hindering the interested developers > from cleaning up the work. > > there is absolutely no reason why this decision should not be taken, > and there are many many reasons why it _should_ be taken. > > not least is the simple fact that the sheer number of issues > that need to be addressed are _far_ too many to keep discussing > in one bugreport. > > it's simply unmanageable. > > so from a purely _practical_ perspective, accept the damn patch and > let's get on and make some damn progress. > On a personal note, I wrote the majority of the Objective-C bindings long before I was employed by Apple. The approach that I took was to generate a few core classes to begin with, and incrementally add more generated source files once the core functionality was in place. This made the review process nice and quick due to the small size of the patches. It also made it easier for me to address comments as they were made, and learn from them.

Luke Kenneth Casson Leighton

Comment 69 2008-10-16 14:19:20 PDT

dear sam, the work done is extensive, comprehensive, and is "too much" for "the system" to cope with. can i therefore recommend that, in order to make progress manageable, that pride takes a back seat? unless paid - cash - i will not be expending further effort to split this patch down into (non-functional) "bite-sizes". you're paid _money_ to work on this code - to ask me to effectively hand-hold you through understanding of the functionality is demeaning to both of us. regarding the outstanding issues: they are documented, here, post-review. every issue requested to be addressed _is_ addressed. that they cannot be conveniently found only serves to emphasis just how important it is that this code _be_ landed, and the outstanding issues addressed _after_ it has been landed. addressed one issue at a time. in convenient bugreport-sized chunks. it's not possible to issue bug-reports within bug-reports and, until this code is landed, you will not receive my cooperation, time or energy _unless_... unless i am paid cash to do further work. then i'll be _delighted_ to help, and will do as _many_ bite-sized patches as it takes and is required. no money - no work. it's too much. sorry.

Mark Rowe (bdash)

Comment 70 2008-10-16 15:22:52 PDT

(In reply to comment #69) > dear sam, > > the work done is extensive, comprehensive, and is "too much" for "the system" > to cope with. can i therefore recommend that, in order to make progress > manageable, that pride takes a back seat? It's a matter of code quality. If the code is not up to our usual standards and it is landed anyway, it becomes an ongoing maintenance burden that *we* as a project have to shoulder. > unless paid - cash - i will not be expending further effort to split this > patch down into (non-functional) "bite-sizes". you're paid _money_ to work > on this code - to ask me to effectively hand-hold you through understanding > of the functionality is demeaning to both of us. You misunderstand what the review process is about. It is about proactively avoid bugs and bringing the quality of the code up to a reasonable standard. We are completely capable of reading and understanding the code. It is because we understand the code we've been able to point out the many outstanding issues in your patch. > regarding the outstanding issues: they are documented, here, post-review. > every issue requested to be addressed _is_ addressed. That is simply not true. The coding style still does not match our well-documented guidelines. Files are missing license headers, and are not named according to our conventions. The patch contains many instances of commented-out code. The ref-counting of wrapped objects is incorrect. There are changes to IDL files which are simply wrong. All of these issues have been raised before. > that they cannot be conveniently found only serves to emphasis just how > important it is that this code _be_ landed, and the outstanding issues > addressed _after_ it has been landed. As we have stated before, all patches must meet the minimum standard for review before they are landed. This patch is not yet at that standard, so it will *not* be landed until it is brought up to that standard. It's as simple as that. > addressed one issue at a time. > > in convenient bugreport-sized chunks. > > it's not possible to issue bug-reports within bug-reports and, until > this code is landed, you will not receive my cooperation, time or energy > _unless_... > > unless i am paid cash to do further work. > > then i'll be _delighted_ to help, and will do as _many_ bite-sized > patches as it takes and is required. > > no money - no work. it's too much. sorry. Asking for payment before you will address review comments is completely inappropriate. If you don't feel inclined to do the work unless someone pays you, that's fine, but please stop saying that we should bypass our review process for your pet patch. A great number of developers contribute to the project, many without compensation, and every one of them follows the same process for refining their patches before they can be landed. There's no requirement that you contribute to this project, and if you're unwilling to do so without payment then perhaps this project isn't for you. In short, if you're not willing to address the issues that we've raised about the patch to sufficient degree to get the patch landed, then at least refrain from taking the discussion in this bug even further off topic than it already is.

Kevin Kubasik

Comment 71 2008-10-16 16:17:25 PDT

Ok, as someone who really does want to see this functionality exposed, let me propose the following. We can agree that a lot of work has gone into this patch, and it is a lot to ask that one person finish everything that needs to be done, and pro-bono none the less. I am not overly familiar with the patch, or the inner workings of webkit, however, I do know how to use an editor, and am more than willing to take care of the cosmetic issues (license headers, code formatting, file naming etc.) if someone else is willing to look at the more technical aspects that I'm not as comfortable with. So how's about it? Are we willing to meet in the middle somewhere and get a _very_ cool feature into WebKit? (In reply to comment #70) > (In reply to comment #69) > > dear sam, > > > > the work done is extensive, comprehensive, and is "too much" for "the system" > > to cope with. can i therefore recommend that, in order to make progress > > manageable, that pride takes a back seat? > > It's a matter of code quality. If the code is not up to our usual standards > and it is landed anyway, it becomes an ongoing maintenance burden that *we* as > a project have to shoulder. > > > unless paid - cash - i will not be expending further effort to split this > > patch down into (non-functional) "bite-sizes". you're paid _money_ to work > > on this code - to ask me to effectively hand-hold you through understanding > > of the functionality is demeaning to both of us. > > You misunderstand what the review process is about. It is about proactively > avoid bugs and bringing the quality of the code up to a reasonable standard. > We are completely capable of reading and understanding the code. It is because > we understand the code we've been able to point out the many outstanding issues > in your patch. > > > regarding the outstanding issues: they are documented, here, post-review. > > every issue requested to be addressed _is_ addressed. > > That is simply not true. The coding style still does not match our > well-documented guidelines. Files are missing license headers, and are not > named according to our conventions. The patch contains many instances of > commented-out code. The ref-counting of wrapped objects is incorrect. There > are changes to IDL files which are simply wrong. All of these issues have been > raised before. > > > that they cannot be conveniently found only serves to emphasis just how > > important it is that this code _be_ landed, and the outstanding issues > > addressed _after_ it has been landed. > > As we have stated before, all patches must meet the minimum standard for review > before they are landed. This patch is not yet at that standard, so it will > *not* be landed until it is brought up to that standard. It's as simple as > that. > > > addressed one issue at a time. > > > > in convenient bugreport-sized chunks. > > > > it's not possible to issue bug-reports within bug-reports and, until > > this code is landed, you will not receive my cooperation, time or energy > > _unless_... > > > > unless i am paid cash to do further work. > > > > then i'll be _delighted_ to help, and will do as _many_ bite-sized > > patches as it takes and is required. > > > > no money - no work. it's too much. sorry. > > Asking for payment before you will address review comments is completely > inappropriate. If you don't feel inclined to do the work unless someone pays > you, that's fine, but please stop saying that we should bypass our review > process for your pet patch. A great number of developers contribute to the > project, many without compensation, and every one of them follows the same > process for refining their patches before they can be landed. There's no > requirement that you contribute to this project, and if you're unwilling to do > so without payment then perhaps this project isn't for you. > > In short, if you're not willing to address the issues that we've raised about > the patch to sufficient degree to get the patch landed, then at least refrain > from taking the discussion in this bug even further off topic than it already > is. >

Mark Rowe (bdash)

Comment 72 2008-10-16 16:21:37 PDT

(In reply to comment #71) > I am not overly familiar with the patch, or the inner workings of webkit, > however, I do know how to use an editor, and am more than willing to take care > of the cosmetic issues (license headers, code formatting, file naming etc.) if > someone else is willing to look at the more technical aspects that I'm not as > comfortable with. > > So how's about it? Are we willing to meet in the middle somewhere and get a > _very_ cool feature into WebKit? Sure, I'd love to see the Gtk port gain this feature so it'd be great if someone wanted to pick up the in-progress patch and polish it up for review. Addressing the cosmetic issues may help get you familiar enough with the patch that you can work on the more technical aspects, and if you feel so inclined you could discuss them with someone on IRC who could assist you with resolving the the issues. Alternatively you could post the cleaned up patch back to this bug and let someone else tackle the remaining work.

Kevin Kubasik

Comment 73 2008-10-16 16:27:46 PDT

That's great to hear! I'll probably be around on the IRC this evening or tomorrow afternoon as I try to clean things up. The coding standards are easy enough to see, and while I can probably guess the file naming conventions,any concrete documentation on that would be helpful.

Luke Kenneth Casson Leighton

Comment 74 2008-10-17 00:16:21 PDT

kevin: GREAT. (because even completing cosmetic changes, now, is too much time) mark: if there were additional cosmetic changes, you should have said so _three weeks_ ago. i began the process of removing comments which indicated that future work and investigation would be needed - and, to be honest, began to get quite pissed off that i was being requested to do so. there has been a hell of a lot done and there is still a hell of a lot _to_ be done, and expecting code to "look perfect" - disallowing people from being able to leave reminders to themselves and to others - doesn't engender a particularly strong desire to continue with the work. i don't have any pets. i addressed cosmetic changes and other changes; explained why issues that you raised _could_ not be addressed, asked you if that was ok .... and have not received a response. please re-read the comments, post-review in each case, and provide additional advice or acceptance of the issues, so that we can proceed. i would be very surprised if you've had any patches to webkit that have totalled 200k and 7,000 lines. it's therefore outside of everybody's comfort zone. you're therefore going need to make some allowances and run by a slightly different set of rules.

Luke Kenneth Casson Leighton

Comment 75 2008-10-17 00:22:06 PDT

> of the cosmetic issues (license headers, code formatting, file naming etc.) if > someone else is willing to look at the more technical aspects that I'm not as > comfortable with. be delighted to act as backup. btw a bugtracker really *is* needed to be used - even just to address the review issues - one bug per issue, so they're not forgotten. (normally, a single bugreport is sufficient).

Mark Rowe (bdash)

Comment 76 2008-10-17 02:45:06 PDT

(In reply to comment #74) > i would be very surprised if you've had any patches to webkit that > have totalled 200k and 7,000 lines. > > it's therefore outside of everybody's comfort zone. > > you're therefore going need to make some allowances and run by > a slightly different set of rules. Luke, your condescending tone is getting tiresome. I had been hoping after reading previous comments that it was purely miscommunication, but it's reached the point that it is clearly intentional. I'll try once more to help you to understand why our processes are they way they are, and why this patch does not get special treatment. The matter of patch review and our standard for the quality of patches that we will land is not up for debate. The size of the patch itself is not inherently a problem, as we have many regular contributors that rework large areas of code in patches larger than this. The reviewers and regular contributors to WebKit are clearly able to comprehend changes to a large code base, after all they regularly work on a project containing over half a million lines of code. The big difference between the patches that these developers contribute and your patch is that these developers are very familiar with how to contribute code to WebKit. They have a deep understanding of the code that they are working with. They understand what quality is expected of the code that they write. They contribute changes in chunks where it possible to do so. They follow our coding style guidelines. You're new to the project, and have not yet had a chance to learn how the project works, and how best to contribute, so it's understandable that your first patches may require a little iteration to be ready to be landed. I understand that the review process can seem a little hostile and rough at first, that it can be easy to take review comments personally at times, and that it can be frustrating for someone to ask you to make further changes before accepting a contribution that you have expended a lot of effort on. The goal is simply to ensure that issues with patches are addressed before they're landed, that the developer improves their skills, and learns how to contribute effectively to the project. Smaller patches lead to quicker reviews with fewer comments that need to be addressed. This accelerates the learning process for new developers, as they can quickly iterate on their initial patches to address reviewer feedback. This quick iteration in turn leads to the contributor getting a feel for the process of submitting a patch to WebKit, and in my experience, greatly improves the quality of their subsequent patches. We have found that asking developers to make a little extra effort up front pays off substantially in terms of the long-term health of the project, which can be seen by the incredible speed at which development on WebKit progresses. If you're not willing to work within the same framework as all of the other contributors to WebKit then you will find it very hard to contribute to the project. If you feel the need to debate this further, I feel that it would be better for everyone involved in the WebKit project if you were to simply walk away. Let's please keep the discussion in this bug to technical issues about the patch from here on in.

Luke Kenneth Casson Leighton

Comment 77 2008-10-17 04:37:24 PDT

(In reply to comment #76) > Luke, your condescending tone is getting tiresome. I had been hoping after > reading previous comments that it was purely miscommunication, but it's reached > the point that it is clearly intentional. it's nothing of the sort. i think ahead - a lot - and then i assume that people will be able to keep up, and fill in the gaps. so, i've reached the conclusion - without necessarily explaining everything - that the most _convenient_ way forward is to relax some of the requirements, and to try a different approach. if you're unable or unwilling to try a different approach, and are unable to work out for yourself that a different approach will work, then i cannot be of further assistance to you, and will wait here patiently until you have exhausted all approaches (that i have already anticipated will be problematic and/or not work). > I'll try once more to help you to understand why our processes are they way > they are, and why this patch does not get special treatment. i understand the process. i do not have an issue with the process. i respect the process. i appreciate the process. and, i have read every word, below, to ensure that i am not missing anything. > I understand that the review process can seem a little hostile and rough at > first, that it can be easy to take review comments personally at times, i have considerable experience with non-egoistic code development, so i am not taking it "personally". what i _do_ have a problem with is when the ball is dropped. i've answered every single one of the issues raised by review, and you haven't even _looked_ at my responses, to say either "no, i insist" or "oh - i see, yes, we're not going to be able to deal with that" or "hmm, i see... well, we're going to let that one pass and we'll raise a separate bugreport about it, to make sure it's not forgotten". > and > that it can be frustrating for someone to ask you to make further changes > before accepting a contribution that you have expended a lot of effort on. i don't mind making changes that are non-disruptive to the functionality. simple things that make the work easier to maintain. i _do_ mind making changes that disrupt the contribution's future maintainability. for example, removing reminders of issues that will at some point need to be addressed, or removing code that was copied from another location, which has justifiable reasons for being there, but because now it's being added for exactly the same reasons, somehow it's now not ok. > goal is simply to ensure that issues with patches are addressed before they're > landed, that the developer improves their skills, and learns how to contribute > effectively to the project. Smaller patches lead to quicker reviews with fewer > comments that need to be addressed. This accelerates the learning process for > new developers, as they can quickly iterate on their initial patches to address > reviewer feedback. This quick iteration in turn leads to the contributor > getting a feel for the process of submitting a patch to WebKit, and in my > experience, greatly improves the quality of their subsequent patches. well, unfortunately, in this instance, the amount of work required to create "working" code - self-consistent and _useful_ code - was considerably higher than a "single small" patch. there _was_ no way to make a "smaller patch" and still provide "useful and working functionality". > If you're not willing to work within the same framework as all of the other > contributors to WebKit then you will find it very hard to contribute to the > project. If you feel the need to debate this further, I feel that it would be > better for everyone involved in the WebKit project if you were to simply walk > away. i already have. if someone pays me money, i will be absolutely _delighted_ to work within the framework as all of the other contributors to webkit. if someone does _not_ pay me money, and i work on this project further, working within the framework that all of the other contributors to webkit do, then i will end up bankrupt, on the streets, and unable to pay for food to put into my mouth. you can't ask me to do that. my gift to you is to provide working code that opens up webkit's reach in a really exciting way. if you are unable to appreciate or accept that gift, by asking that it be supplied in a specific way, by asking for _more_ from me - that's not really ok, is it? if you're willing to read my review-responses, and respond to them, we can move forward. if you're not, then i trust that you will work out all of the issues, yourself, and, when you re-encounter the issues i've _already_ faced (and answered), i trust that you will find appropriate solutions and, if you can't, will have the good sense to ask my advice. > Let's please keep the discussion in this bug to technical issues about the > patch from here on in. great. good idea. now. have you read my comments and responses to the reviews?

Gustavo Noronha (kov)

Comment 78 2008-10-17 06:23:09 PDT

Martín Soto

Comment 79 2008-10-17 07:57:41 PDT

(In reply to comment #66) > (In reply to comment #65) ... > Please read back over the review comments I have left on a previous version of > the patch. There are many issues which have not yet been addressed and which > need to be addressed before this can be landed. In general though, this patch > is trying to do far too much at once which makes it very hard to get right > without going through many iterations, and it also makes it a lot of work to > review. An initial cut at the bindings that supports a subset of the > functionality would be much quicker to clean up and get into a usable state, > and would make it simple for others to finish off the work in parallel. I suppose you're referring here to comment #46. In order to concentrate on technical issues, as you wisely suggest in a later comment, let me go through the points you made there. I'll mark the issues as follows: (A) Already addressed issue. (O) Open, serious issue, which probably requires further work. (E) Easy to fix, probably something Kevin can do in his current clean-up job (by the way, thanks for the offer!) >From comment #46: > Can you please name the generated files with a format that matches our coding > style? "GdomBarInfo.h" doesn't match our naming conventions, and should > probably be GDOMBarInfo.h. If these files are to be part of the WebKit GTK API > then they should match the GTK naming convention, which I believe does not use > upper-case letters at all. Alp may be able to provide suggestions about what > the right naming scheme is here. (E) As far as I see, generated files are still being named using the Gdom prefix instead of GDOM, which is inconsistent with the convention used for the JavaScript files (they use "JS" not "Js" as prefix). This must be corrected. (E) This is also a problem for identifiers in general: they sometimes start with GDOM and sometimes with Gdom. I propose to use GDOM consistently. This would probably also imply renaming GdomDOMObject to GDOMObject, because GDOMDOMObject would look sort of funny. > The changes in FrameLoaderClientGtk.cpp look bogus. Why are they in this > patch? (O) As Luke states in comment #48, these changes were needed for the patch to run at all (he didn't receive any answer to that, by the way). The way it looks, there seems to be a refcounting problem somewhere, either introduced, or exposed by the patch. Unfortunately, I'm too much of a WebKit novice to be able to debug this. > Why does GDOMObject.h have a commented out 'namespace WebCore'? Why does it > have a function named get_gobj_type which doesn't match our naming conventions? (A) No commented out namespace anymore. The function was renamed to getGobjType, so this was addressed. > The includes in webkitwebframe.cpp should be sorted per our style conventions. > They also shouldn't have the "gdom/" prefix. The private header files should > be have Private as a suffix to match the convention used elsewhere in the > project (PrivateGdomDOMWindow.h -> GDOMWindowPrivate.h). It's not clear to me > why some of the files have "Int" in their name. Is that short for "Internal"? > If so, the file should use that as a suffix in place of Private, such as > GDOMWindowInternal.h. (A) Includes are now sorted, and "Internal" and "Private" are being used as stated. This part was addressed. (E) I still see quite a few includes with a gdom/ prefix, though. This must be fixed. > There are commented-out printf's in webkitwebevent.cpp which shouldn't be > there. (E) There are still three commented print statements in the patch. > PrivateIntGdomEventTargetNode.h lacks a license header, and the Apple Inc. > copyright line lacks the "All rights reserved." note that should be present. > The file also uses strange formatting for the include guard. Please see > existing code for an example of the style that should be used. (E) This wasn't addressed at all. Also, there are more instances where the Apple copyright lacks the "all rights reserved" sentence. > The code in GStringConvert.h lacks a license header. I'm not sure what the > point of the GStringConvert class is. It seems like it could easily be > implemented using a simple overloaded function rather than the strange class + > macro combination. The "extern C" around a C++ class doesn't make a lot of > sense either. The header includes in this file also need sorted. (A) GStringConvert is now a set of overloaded functions. This being the case, (E) the name shouldn't be capitalized, though. There is now a license header. > Do the values for FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT ever > differ? If not, is there any point in having both? (O) I cannot address this so easily. > GDOMHTMLElementWrapperFactory.cpp says that "THIS FILE IS DERIVED FROM AN > AUTOMATICALLY GENERATED FILE." what file is it derived from, and why is it > being checked in if it is a generated file? This file now contains a yelling comment stating that + * THIS FILE IS DERIVED BY HAND FROM AN AUTOMATICALLY GENERATED FILE. + * IT IS NOT AN AUTO-GENERATED FILE IT WAS CREATED MANUALLY *FROM* + * AN AUTO-GENERATED FILE. (E) We probably should restate this comment to make it more friendly. (O) Also, even if the file can probably be generated, would people agree with keeping it in the current for for the time being before we can write a generator? > GDOMBinding.cpp has some FIXME's, TODO's and a lot of commented-out code that > should be cleaned up before this can be landed. (E) This seems to still be the case. Luke has stated elsewhere that he wants all of these comments and pieces of dead code as reminders, but we probably have to remove them in order for the patch to be accepted. By the way, are TODO or FIXME remarks completely banned from WebKit? Are they acceptable in any form? I can't find any project documentation covering this point. > Some of the IDL file changes do not look correct. I would think that the > GObject bindings would want to match the behaviour of the Obj-C DOM bindings > rather than JS in the cases that they differ. Many of these instances are due > to behavioral peculiarities of JS, especially attributes such as > ConvertNullToNullString and toString functions. (O) Luke has answered to this issue in a number of further comments, but I don't see any replies to them. A good deal of communication seems to have happened outside of Bugzilla, so it is hard for me to determine the status of this issue. So, provided Kevin manages to get rid of the "easy" problems, four large issues remain: 1. Refcounting problems. 2. Equivalence of FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT. 3. Keeping GDOMHTMLElementWrapperFactory.cpp as a manually edited file. 4. Changes to the IDL files. Any additional problems I'm missing? Could people please post their thoughts on the open issues so that we can make some progress? I'll try to look into issue 4 and see if I can understand what's going on, but cannot promise anything for the moment.

Luke Kenneth Casson Leighton

Comment 80 2008-10-17 09:22:29 PDT

> I suppose you're referring here to comment #46. In order to concentrate > on technical issues, as you wisely suggest in a later comment, let me go > through the points you made there. I'll mark the issues as follows: yaay! thank you!

Luke Kenneth Casson Leighton

Comment 81 2008-10-17 09:29:48 PDT

comments #48, #49, #50, #51 and #52 answer review issues, raise queries regarding review issues and/or provide justifications as to why review issues _cannot_ be addressed. mark, please kindly respond to the comments in #48 to #52. thank you. [please be aware: unfortunately, sufficient time has elapsed since the code was written, such that i am unable, without considerable effort, to provide effortless and timely answers, should there be any queries regarding my responses in #48 to #52. however, i will do my best to answer, as long as it does not take up significant time]. l.

Luke Kenneth Casson Leighton

Comment 82 2008-10-17 09:41:48 PDT

> (O) As Luke states in comment #48, these changes were needed for the > patch to run at all (he didn't receive any answer to that, by the way). yes, i didn't. (that is the key reason why i was annoyed) > The way it looks, there seems to be a refcounting problem somewhere, > either introduced, or exposed by the patch. well, if i remove the code from GDOMBinding.cpp which is designed to help debug refcounting problems, we can't FIND OUT, CAN WE!!! :) and yes, at the request of the reviewers, i have been forced to remove it, because it had "#ifdef 0" around it. explanations in the code from which it was cut-and-paste - from JSBindings - state that the code is [even #ifdef'd out there] necessary to check for refcounting errors. leaving that aside: i am reasonably confident that, having used RefPtr in the right places, and having done ref increasing in the constructors, and ref decreasing in the destructors, i am reasonably confident that there are not any refcount errors. certainly, the code can be utilised for exceptionally large and complex applications for prolonged periods of time, and "nothing bad happens", leading me to conclude, empirically, that at least there are no _zero_ referencing errors or _negative_ referencing errors. whether there are any "over" referenced errors, resulting in memory leaks, will need some investigation. i forget, unfortunately, how and where the refcounting is increased and decreased. certainly, the code to do both is auto-generated by the gobject bindings perl module, so you will need to run it and then look in .... damn i've even forgotten the name of the directory where the generated sources go.

Mark Rowe (bdash)

Comment 83 2008-10-17 13:50:37 PDT

(In reply to comment #79) > I suppose you're referring here to comment #46. In order to concentrate > on technical issues, as you wisely suggest in a later comment, let me go > through the points you made there. Thanks for taking the time to summarise this. > > The changes in FrameLoaderClientGtk.cpp look bogus. Why are they in this > > patch? > > (O) As Luke states in comment #48, these changes were needed for the > patch to run at all (he didn't receive any answer to that, by the way). > The way it looks, there seems to be a refcounting problem somewhere, > either introduced, or exposed by the patch. Unfortunately, I'm too much > of a WebKit novice to be able to debug this. It looks as though this is an attempt to work around an issue tracked by bug 20403. The correct solution here is probably to finish off the fix for bug 20403 and remove this code from FrameLoaderClientGtk.cpp. > > > Why does GDOMObject.h have a commented out 'namespace WebCore'? Why does it > > have a function named get_gobj_type which doesn't match our naming conventions? > > (A) No commented out namespace anymore. The function was renamed to > getGobjType, so this was addressed. Minor issue: getGobjType doesn't follow the naming conventions outlined in the coding style guidelines, due to the same capitalization inconsistency that "Gdom" has in some places in this patch. > > Do the values for FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT ever > > differ? If not, is there any point in having both? > > (O) I cannot address this so easily. The reason that I asked this is that the Mac port uses the same variable in its Makefile (WebCore/DerivedSources.make) for the defines of both JS and Obj-C bindings. It should be easy to unify them for GDOM too. Is the only difference that at the moment the GDOM binding lacks SVG support? At the very least this shouldn't require duplication of assignments for each possible feature define. The common values could be assigned to a FEATURE_DEFINES variable, with FEATURE_DEFINES_JAVASCRIPT taking its value and adding LANGUAGE_JAVASCRIPT, ENABLE_SVG, etc, and FEATURE_DEFINES_GDOM only adding LANGUAGE_GDOM. Another alternative would be to have FEATURE_DEFINES include all features that are enabled, and FEATURE_DEFINES_GDOM be the result of stripping out any values that mention SVG from the FEATURE_DEFINES variable. > > > GDOMHTMLElementWrapperFactory.cpp says that "THIS FILE IS DERIVED FROM AN > > AUTOMATICALLY GENERATED FILE." what file is it derived from, and why is it > > being checked in if it is a generated file? > > This file now contains a yelling comment stating that > > + * THIS FILE IS DERIVED BY HAND FROM AN AUTOMATICALLY GENERATED FILE. > + * IT IS NOT AN AUTO-GENERATED FILE IT WAS CREATED MANUALLY *FROM* > + * AN AUTO-GENERATED FILE. > > (E) We probably should restate this comment to make it more friendly. The comment could be as simple as: // FIXME: This file should be auto-generated in the future <https://bugs.webkit.org/show_bug.cgi?id=some-bug-number>. It should be moved below the license header though. > (O) Also, even if the file can probably be generated, would people agree > with keeping it in the current for for the time being before we can > write a generator? It would definitely be preferable to generate this automatically, but it's not clear what the right way to do this would be at this point. The Obj-C binding currently has this hard-coded, so that seems fine as a first step for this patch. > > GDOMBinding.cpp has some FIXME's, TODO's and a lot of commented-out code that > > should be cleaned up before this can be landed. > > (E) This seems to still be the case. Luke has stated elsewhere that he > wants all of these comments and pieces of dead code as reminders, but we > probably have to remove them in order for the patch to be accepted. > > By the way, are TODO or FIXME remarks completely banned from WebKit? Are > they acceptable in any form? I can't find any project documentation > covering this point. A grep through WebCore will show that we have numerous FIXMEs in the code. The typical form of the FIXME in our code is like what I suggested above: a short description of the issue that needs to be addressed, and a link to a bug about addressing that issue in the future. FIXMEs are not an excuse to leave commented-out code in the tree. New code should follow the consistent style I have mentioned, rather than a mismatch of styles such as the following: 153 #if 0 /* XXX TODO - see #20586 */ 463 return NULL; /* TODO - see #20586 */ 513 return NULL; /* XXX hmmm... */ 29 /* TODO: make a GdomEventListener class, to be returned here */ 3412 #FEATURE_DEFINES_GDOM += ENABLE_SVG_USE=1 # big TODO! > > Some of the IDL file changes do not look correct. I would think that the > > GObject bindings would want to match the behaviour of the Obj-C DOM bindings > > rather than JS in the cases that they differ. Many of these instances are due > > to behavioral peculiarities of JS, especially attributes such as > > ConvertNullToNullString and toString functions. > > (O) Luke has answered to this issue in a number of further comments, but > I don't see any replies to them. A good deal of communication seems to > have happened outside of Bugzilla, so it is hard for me to determine the > status of this issue. I do recall discussing this with him on IRC. I'll look back over his comments shortly and add my thoughts to this bug. > So, provided Kevin manages to get rid of the "easy" problems, four large > issues remain: > > 1. Refcounting problems. There are two issues here: the ref-counting problems tracked in bug 20403, which sound as though they need to be addressed before these bindings will function without crashing, and the ref-counting problems within the patch itself. > 2. Equivalence of FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT. I don't think this is a large issue that would be especially difficult to address. > 3. Keeping GDOMHTMLElementWrapperFactory.cpp as a manually edited file. Nor this. > 4. Changes to the IDL files. > > Any additional problems I'm missing? Could people please post their > thoughts on the open issues so that we can make some progress? I'll try > to look into issue 4 and see if I can understand what's going on, but > cannot promise anything for the moment.

Mark Rowe (bdash)

Comment 84 2008-10-17 14:13:02 PDT

(In reply to comment #82) > > The way it looks, there seems to be a refcounting problem somewhere, > > either introduced, or exposed by the patch. > > well, if i remove the code from GDOMBinding.cpp which is designed to > help debug refcounting problems, we can't FIND OUT, CAN WE!!! > and yes, at the request of the reviewers, i have been forced to remove it, > because it had "#ifdef 0" around it. > > explanations in the code from which it was cut-and-paste - from JSBindings - > state that the code is [even #ifdef'd out there] necessary to check for > refcounting errors. The equivalent code in JSDOMBindings.cpp is not wrapped in #if 0. It is code that is compiled in and actively used. For this code to be useful in the GDOM bindings it too needs to be actively used. Having it #if'd out does not accomplish that. It should either be left in and actively used, or removed and replaced with a FIXME about adding such functionality in the future. > i am reasonably confident that, having used RefPtr in the right places, > and having done ref increasing in the constructors, and ref decreasing > in the destructors, i am reasonably confident that there are not any > refcount errors. I've not looked at code generated by the bindings script, but from inspection of the script itself and the hand-written code I can see several errors. 678 push(@cBody, " m_impl.get()->deref();\n"); Explicitly calling deref() on a reference held in a RefPtr is a sure sign that ref-counting is being handled incorrectly. A RefPtr will automatically call deref() when it is destroyed, so by calling deref explicitly you're decrementing the ref-count on this object twice. I don't think the generated bindings code should be calling ref() or deref() explicitly at all. Managing the lifetimes of the wrapped objects via a RefPtr is almost certainly sufficient. The manual calls to ref() and deref() in GDOMBinding.cpp also hint at ref-counting being handled incorrectly, and perhaps indicate why you believed it was necessary to deref() from within the generated code. 506 text->document()->ref(); If a manual ref() were required here, which it's not, ref'ing the document is definitely not correct here. There is some documentation at <http://webkit.org/coding/RefPtr.html> on how to use RefPtr and PassRefPtr to efficiently handle our reference counted objects.

Mark Rowe (bdash)

Comment 85 2008-10-17 14:42:07 PDT

(In reply to comment #50) > --- WebCore/html/HTMLEmbedElement.idl (revision 36459) > +++ WebCore/html/HTMLEmbedElement.idl (working copy) > @@ -30,7 +30,7 @@ > ImplementationUUID=93e0407a-8380-4ff0-978d-f773f2dee6a3 > ] HTMLEmbedElement : HTMLElement { > attribute [ConvertNullToNullString] DOMString align; > -#if defined(LANGUAGE_JAVASCRIPT) > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > attribute [ConvertNullToNullString] DOMString height; > #else > attribute [ConvertFromString] long height; > @@ -38,7 +38,7 @@ > attribute [ConvertNullToNullString] DOMString name; > attribute [ConvertNullToNullString] DOMString src; > attribute [ConvertNullToNullString] DOMString type; > -#if defined(LANGUAGE_JAVASCRIPT) > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > attribute [ConvertNullToNullString] DOMString width; > #else > attribute [ConvertFromString] long width; > > > > exact same functionality as javascript is required. an int width > and an int height is of absolutely no use. > > pyjamas-desktop needs to be able to set width and height to what > _javascript_ does - not objectiveC. > > i.e. "100%". "10em". "20px". The width and height properties of the DOM specification are defined as being longs, so that is what they should be exposed to all bindings as. JavaScript is a special case as there is the requirement for compatibility with the millions of real-world web pages that were coded to the initial implementations of the DOM in browsers that did not adhere to the spec. It's worth noting that setting the .width or .height properties of a HTMLEmbedElement to "10em", "10en", or any other value followed by a CSS unit is unlikely to do what you think. > the integer-only parameters are no use to anyone wishing to maintain > line-for-line javascript equivalent functionality, which is what > pyjamas-desktop is about: ripping out the javascript and replacing it with > exact-equivalent code, written in python instead of javascript. That may be what your project is about, but it's not what DOM bindings in WebKit are about. DOM bindings are about exposing the standard WebKit DOM to client applications, not about exposing JavaScript's somewhat warped interpretation of the DOM.

Mark Rowe (bdash)

Comment 86 2008-10-17 14:44:05 PDT

(In reply to comment #52) > --- WebCore/page/DOMWindow.idl (revision 36459) > +++ WebCore/page/DOMWindow.idl (working copy) > @@ -155,7 +155,7 @@ > [DoNotCheckDomainSecurity, Custom] void postMessage(in DOMString > message, in DOMString targetOrigin) > raises(DOMException); > > -#if defined(LANGUAGE_JAVASCRIPT) > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > // Global constructors > attribute StyleSheetConstructor StyleSheet; > attribute CSSStyleSheetConstructor CSSStyleSheet; > > i've added this in as a reminder that, at some point _in the future_, > the gobject auto-generator code will need to auto-generate "constructors". > i believe this was part of the problem i had in doing creation of a > document - not having some of these functions. > > although it will be straightforward to add constructors, i'm not doing > it for this patch. Constructors are JavaScript language concept. They're not something that other bindings need to worry about.

Mark Rowe (bdash)

Comment 87 2008-10-17 14:53:01 PDT

#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) [DontEnum] DOMString toString(); #endif toString() is also a JavaScript language concept that other bindings need to worry about.

Luke Kenneth Casson Leighton

Comment 88 2008-10-17 16:09:36 PDT

(In reply to comment #87) > #if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > [DontEnum] DOMString toString(); > #endif > > toString() is also a JavaScript language concept that other bindings need to > worry about. i do keep explaining - but it's been a while so i will explain it again: javascript is the language that i am targetting as providing _direct_ one-for-one, concept-for-concept, function-for-function, class-for-class, attribute-for-attribute equivalence (as closely as possible). this approach allows developers who are _expecting_ to see javascript, _understand_ javascript and program regularly in javascript to _not_ get any nasty surprises when they are presented with the glib bindings, and other language bindings to those. the same thing goes for the "constructors" (if i can get my head round why they're used). the same thing also goes for the suggestion that you made that i should provide only "integer" input to setWidth() and other functions, because that's what ObjC does. the answer's "no - absolutely not". people who expect to pass in "3em", "10px", "50%" will get a nasty shock. and yes, i really really _do_ need toString() because it's actually _used_ in the pyjamas-desktop DOM.py module. remember, i'm translating the javascript (by hand, unfortunately) in pyjamas into DIRECT and IDENTICAL function calls (in python) that end up calling the webkit-glib bindings. if i get *any* discrepancies (such as not having toString), then all of a sudden i'm screwed, because there's a difference between the pyjamas code (javascript compiler) and the pyjamas-desktop code (webkit-based).

Luke Kenneth Casson Leighton

Comment 89 2008-10-17 16:37:17 PDT

> > (O) As Luke states in comment #48, these changes were needed for the > > patch to run at all (he didn't receive any answer to that, by the way). > > The way it looks, there seems to be a refcounting problem somewhere, > > either introduced, or exposed by the patch. Unfortunately, I'm too much > > of a WebKit novice to be able to debug this. > > It looks as though this is an attempt to work around an issue tracked by bug > 20403. The correct solution here is probably to finish off the fix for bug > 20403 and remove this code from FrameLoaderClientGtk.cpp. #20403 is done. solved. [but has been languishing for some weeks, even though it's been noted as "the correct solution"] the hack-attempt has already been removed. the last-updated patch _should_ reflect that. apologies if it's still included. let's hope people aren't working on out-of-date patches (!) > > > > > Why does GDOMObject.h have a commented out 'namespace WebCore'? Why does it > > > have a function named get_gobj_type which doesn't match our naming conventions? > > > > (A) No commented out namespace anymore. The function was renamed to > > getGobjType, so this was addressed. > > Minor issue: getGobjType doesn't follow the naming conventions outlined in the > coding style guidelines, due to the same capitalization inconsistency that > "Gdom" has in some places in this patch. i've read the guidelines - i don't understand what i'm missing. btw i started off with GDOM as the prefix and it blew up the pygtk auto-generator. i posted a bugreport about that and they said that there was absolutely zero intention of fixing pygtk's codegen.py. so, you _can_ go and replace Gdom with GDOM, and it will screw things up for people, further down the line. > > > Do the values for FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT ever > > > differ? If not, is there any point in having both? > > > > (O) I cannot address this so easily. > > The reason that I asked this is that the Mac port uses the same variable in its > Makefile (WebCore/DerivedSources.make) for the defines of both JS and Obj-C > bindings. It should be easy to unify them for GDOM too. Is the only > difference that at the moment the GDOM binding lacks SVG support? pretty much. > At the very > least this shouldn't require duplication of assignments for each possible > feature define. The common values could be assigned to a FEATURE_DEFINES > variable, with FEATURE_DEFINES_JAVASCRIPT taking its value and adding > LANGUAGE_JAVASCRIPT, ENABLE_SVG, etc, and FEATURE_DEFINES_GDOM only adding > LANGUAGE_GDOM. Another alternative would be to have FEATURE_DEFINES include > all features that are enabled, and FEATURE_DEFINES_GDOM be the result of > stripping out any values that mention SVG from the FEATURE_DEFINES variable. i _may_ be wrong about this: i wouldn't recommend that _at the moment_, because the person who will be expected to create the SVG bindings in the future may choose to implement a _small_ subset of the SVG bindings, to begin with. if the above paragraph translates into "when someone comes to adding SVG bindings, then they will either have to implement them all or not at all", then it should be clear as to why that is undesirable. > > > > > GDOMHTMLElementWrapperFactory.cpp says that "THIS FILE IS DERIVED FROM AN > > > AUTOMATICALLY GENERATED FILE." what file is it derived from, and why is it > > > being checked in if it is a generated file? > > > > This file now contains a yelling comment stating that > > > > + * THIS FILE IS DERIVED BY HAND FROM AN AUTOMATICALLY GENERATED FILE. > > + * IT IS NOT AN AUTO-GENERATED FILE IT WAS CREATED MANUALLY *FROM* > > + * AN AUTO-GENERATED FILE. > > > > (E) We probably should restate this comment to make it more friendly. > > The comment could be as simple as: > // FIXME: This file should be auto-generated in the future > <https://bugs.webkit.org/show_bug.cgi?id=some-bug-number>. yaay. > It should be moved below the license header though. > > > (O) Also, even if the file can probably be generated, would people agree > > with keeping it in the current for for the time being before we can > > write a generator? > > It would definitely be preferable to generate this automatically, but it's not > clear what the right way to do this would be at this point. The Obj-C binding > currently has this hard-coded, so that seems fine as a first step for this > patch. yaay! (whew) > > > GDOMBinding.cpp has some FIXME's, TODO's and a lot of commented-out code that > > > should be cleaned up before this can be landed. > > > > (E) This seems to still be the case. Luke has stated elsewhere that he > > wants all of these comments and pieces of dead code as reminders, but we > > probably have to remove them in order for the patch to be accepted. > > > > By the way, are TODO or FIXME remarks completely banned from WebKit? Are > > they acceptable in any form? I can't find any project documentation > > covering this point. > > A grep through WebCore will show that we have numerous FIXMEs in the code. The > typical form of the FIXME in our code is like what I suggested above: a short > description of the issue that needs to be addressed, and a link to a bug about > addressing that issue in the future. FIXMEs are not an excuse to leave > commented-out code in the tree. New code should follow the consistent style I > have mentioned, rather than a mismatch of styles such as the following: > > 153 #if 0 /* XXX TODO - see #20586 */ > > 463 return NULL; /* TODO - see #20586 */ > > 513 return NULL; /* XXX hmmm... */ > > 29 /* TODO: make a GdomEventListener class, to be returned here */ > > 3412 #FEATURE_DEFINES_GDOM += ENABLE_SVG_USE=1 # big TODO! whoops :) > > > Some of the IDL file changes do not look correct. I would think that the > > > GObject bindings would want to match the behaviour of the Obj-C DOM bindings no. definitely not. i had to re-activate ... i think it was... XMLHTTPRequest.open(String) because i couldn't find a way to create a Text Document (there was no global constructor for one, and i hadn't put in the equivalent of the "Global Attributes" in _order_ to make one). simplest solution: pass in a text string rather than a WebCore::(Text)Document. so on a case-by-case basis, there are _going_ to be differences, and at no time - as of yet - have i found that i needed to copy the ObjC bindings behaviour (IDL-wise), but have, in each case, found that the JS bindings are a better fit. of course, that may change: each case has its own set of issues to work around. > > > rather than JS in the cases that they differ. Many of these instances are due > > > to behavioral peculiarities of JS, especially attributes such as > > > ConvertNullToNullString and toString functions. ConvertNullToNullString: agreed. (well, i haven't used it, and pyjamas-desktop hasn't blown up. so i don't need it). toString: disagree. _definitely_ need this one. > > (O) Luke has answered to this issue in a number of further comments, but > > I don't see any replies to them. A good deal of communication seems to > > have happened outside of Bugzilla, so it is hard for me to determine the > > status of this issue. > > I do recall discussing this with him on IRC. I'll look back over his comments > shortly and add my thoughts to this bug. > > > So, provided Kevin manages to get rid of the "easy" problems, four large > > issues remain: > > > > 1. Refcounting problems. > > There are two issues here: the ref-counting problems tracked in bug 20403, > which sound as though they need to be addressed before these bindings will > function without crashing, no. 1) the crashes caused by #20403 have been demonstrated and proven to have absolutely nothing to do with the bindings. at all. nothing. 2) #20403 has been solved. > and the ref-counting problems within the patch > itself. there have been _no_ ref-counting problems encountered. see earlier comment: i would be utterly shocked if there were "negative" refcounting bugs, because of the amount of time i've spent running pyjamas-desktop apps. without crashes of any kind (esp. since i patched in the solution #20403) i would equally be surprised if there were memory leaks, but you can clearly see, if you examine an auto-generated file, that each and every "add ref" is matched by a corresponding "dec ref". so, although it's not _proven_, with test code, this "refcounting problem" sounds much like an imaginary invention - a bogeyman in the closet :) > > 2. Equivalence of FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT. > > I don't think this is a large issue that would be especially difficult to > address. > > > 3. Keeping GDOMHTMLElementWrapperFactory.cpp as a manually edited file. > > Nor this. whew. small project for someone, at some point. i'd recommend that the auto-generation be done at around the same time that DOMExceptions are re-added to the rest of the code. re-adding in the DOMExceptions (that i ripped out, so as to get a first version), would be an utter pain to do manually. much better to auto-generate a replacement for DOMHTMLElementWrapperFactory.cpp btw - this _should_ be raised as a separate bugreport. > > 4. Changes to the IDL files. > > > > Any additional problems I'm missing? Could people please post their > > thoughts on the open issues so that we can make some progress? I'll try > > to look into issue 4 and see if I can understand what's going on, but > > cannot promise anything for the moment. i wouldn't make the differences without very good reasons and justification. XMLHTTPRequest open(String) is a good starting point: it's simply too much additional work to provide the functionality of TextDocument, when just enabling the use of open(String) instead of open(TextDocument) will do just as well, if not better. each of the differences is pretty obvious and straightforward, and i believe i've answered and explained them all.

Luke Kenneth Casson Leighton

Comment 90 2008-10-17 16:52:51 PDT

(In reply to comment #85) > (In reply to comment #50) > > --- WebCore/html/HTMLEmbedElement.idl (revision 36459) > > +++ WebCore/html/HTMLEmbedElement.idl (working copy) > > @@ -30,7 +30,7 @@ > > ImplementationUUID=93e0407a-8380-4ff0-978d-f773f2dee6a3 > > ] HTMLEmbedElement : HTMLElement { > > attribute [ConvertNullToNullString] DOMString align; > > -#if defined(LANGUAGE_JAVASCRIPT) > > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > > attribute [ConvertNullToNullString] DOMString height; > > #else > > attribute [ConvertFromString] long height; > > @@ -38,7 +38,7 @@ > > attribute [ConvertNullToNullString] DOMString name; > > attribute [ConvertNullToNullString] DOMString src; > > attribute [ConvertNullToNullString] DOMString type; > > -#if defined(LANGUAGE_JAVASCRIPT) > > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > > attribute [ConvertNullToNullString] DOMString width; > > #else > > attribute [ConvertFromString] long width; > > > > > > > > exact same functionality as javascript is required. an int width > > and an int height is of absolutely no use. > > > > pyjamas-desktop needs to be able to set width and height to what > > _javascript_ does - not objectiveC. > > > > i.e. "100%". "10em". "20px". > > The width and height properties of the DOM specification are defined as being > longs, so that is what they should be exposed to all bindings as. wrong. absolutely wrong. if in the "real world", because of javascript - exactly as you say - people pass in things OTHER than integers, then the DOM specification can take a hike! > JavaScript > is a special case as there is the requirement for compatibility with the > millions of real-world web pages that were coded to the initial implementations > of the DOM in browsers that did not adhere to the spec. and thus this is EXACTLY the reason why the glib bindings MUST, i repeat, MUST, i repeat MUST provide EXACTLY the same functionality. how are we supposed to tell people, "if you port your application from javascript to use a high-level-language that binds to webkit-glib bindings, you can do everything you expect to be able to do in javascript.... oh, _except_ you can't use "20px", you _have_ to specify "20", and you can't use "100%", you have to work out the percentage yourself". no, no, no and no. > It's worth noting that setting the .width or .height properties of a > HTMLEmbedElement to "10em", "10en", or any other value followed by a CSS unit > is unlikely to do what you think. ... how intriguing. i've never _used_ em or en in any apps, but _have_ used px and %, and found them to work in all cases where they're used, and found them to work as expected. > > the integer-only parameters are no use to anyone wishing to maintain > > line-for-line javascript equivalent functionality, which is what > > pyjamas-desktop is about: ripping out the javascript and replacing it with > > exact-equivalent code, written in python instead of javascript. > > That may be what your project is about, it's "my" project, it's _a_ project that i happen to be working on, at present. let's reinterpret this sentence, and go from there: > That may be what that one example project is about, yes, it's one example - that demonstrates why it is necessary to follow javascript's lead, rather than a rigid (and ignored) standard. the _very fact_ that people have ignored the DOM specification _immediately_ says that the glib bindings MUST expose EXACTLY the same functionality as javascript. NOT the rigid and non-adhered to standard. > but it's not what DOM bindings in > WebKit are about. DOM bindings are about exposing the standard WebKit DOM to > client applications, which is useless, as demonstrated by the warped javascript _real world_ interpretation. be pragmatic. > not about exposing JavaScript's somewhat warped > interpretation of the DOM. javascript _is_ the standard. it wins. de-facto. there's no putting the genie back in the bottle - it's too late. javascript wins. get the standard updated. plus, the reason _why_ people specify "75%", "20px", "10em" etc is because _only_ being able to specify an integer is bloody useless! being able to specify "75%" is a _damn_ good idea. so - following JS bindings it is.

Mark Rowe (bdash)

Comment 91 2008-10-17 16:55:20 PDT

(In reply to comment #88) > (In reply to comment #87) > > #if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > > [DontEnum] DOMString toString(); > > #endif > > > > toString() is also a JavaScript language concept that other bindings need to > > worry about. > > i do keep explaining - but it's been a while so i will explain it again: > javascript is the language that i am targetting as providing _direct_ > one-for-one, concept-for-concept, function-for-function, class-for-class, > attribute-for-attribute equivalence (as closely as possible). In that case, your objective is not the same as the objectives of the DOM bindings in WebKit. As I have stated, they are designed to wrap the standard WebKit DOM, and only to expose quirks to JavaScript where they are required for compatibility with other browsers. > this approach allows developers who are _expecting_ to see javascript, > _understand_ javascript and program regularly in javascript to _not_ get any > nasty surprises when they are presented with the glib bindings, and other > language bindings to those. The DOM is not JavaScript. I don't think the argument that a developer expects to see JavaScript semantics from a non-JavaScript DOM binding holds much weight. We've had no complaints of this nature, about the Objective-C DOM bindings in the many years that they have been part of the project. > the same thing goes for the "constructors" (if i can get my head round why > they're used). Are you seriously arguing that you must have something that you don't understand? The JavaScript constructors are used only for gaining access to the prototype object, a JavaScript concept, which simply does not make sense for other DOM bindings. > the same thing also goes for the suggestion that you made that i should > provide only "integer" input to setWidth() and other functions, because that's > what ObjC does. > > the answer's "no - absolutely not". people who expect to pass in "3em", > "10px", "50%" will get a nasty shock. As I have already stated, people that try and set .width or .height "3em" will already get a nasty shock, even from JavaScript. It does not do what you think that it does. > and yes, i really really _do_ need toString() because it's actually _used_ in > the pyjamas-desktop DOM.py module. This argument doesn't carry much weight, as it could be used to get *any* change in to WebKit. It can be generalised to: "I've written some code in another project that depends on my work-in-progress patch, therefore you have to accept this change in to WebKit in order to not break that code." All of the objects that provide a .toString() function to JavaScript there are native DOM methods to return the same data. Applications using the native DOM bindings can simply use the appropriate methods to retrieve this information. > remember, i'm translating the javascript (by hand, unfortunately) in pyjamas > into DIRECT and IDENTICAL function calls (in python) that end up calling the > webkit-glib bindings. > > if i get *any* discrepancies (such as not having toString), then all of a > sudden i'm screwed, because there's a difference between the pyjamas code > (javascript compiler) and the pyjamas-desktop code (webkit-based). I think you need to keep in mind that DOM bindings in WebKit do not exist solely for the benefit of your project. Your project, as the first user of the DOM bindings, certainly influences what the initial cut will support, but it in no way defines what they *must* support.

Luke Kenneth Casson Leighton

Comment 92 2008-10-17 17:15:00 PDT

> I don't think the generated bindings code should be calling ref() or deref() > explicitly at all. Managing the lifetimes of the wrapped objects via a RefPtr > is almost certainly sufficient. then why did the code crash, without them (without the ref and deref), and why are the ObjC bindings using the ref and deref technique, which i am copying, verbatim? btw i've taken a quick look at the GDOMBindings.cpp, i believe i may have spotted an error, in the toGDOM(Element*) implementation. comparing each call of ref(), there are a couple that are inconsistent: one calls doc->ref() which i don't think it should. ... but... i copied this technique from JSBindings and ObjC bindings - why should these bindings be different? > There is some documentation at <http://webkit.org/coding/RefPtr.html> on how to > use RefPtr and PassRefPtr to efficiently handle our reference counted objects. thank you. although i remember, clearly, your very helpful explanations on IRC some weeks back, i'll read it over the next day or two to ensure i haven't missed anything. .... well ... y'know... it's been long enough so i honestly can't say. it's probably worthwhile someone taking out the ref()s in GDOMBindings.cpp, commenting out that deref auto-generator line in GObject.pm, and testing a pyjamas-desktop app with pywebkitgtk. (which may prove to be a shorter way to do a test than to write some c code, although a "hello world" direct use of the glib functions _would_ be really useful, and cool to see).

Mark Rowe (bdash)

Comment 93 2008-10-17 17:19:29 PDT

(In reply to comment #89) > > Minor issue: getGobjType doesn't follow the naming conventions outlined in the > > coding style guidelines, due to the same capitalization inconsistency that > > "Gdom" has in some places in this patch. > > i've read the guidelines - i don't understand what i'm missing. """ Use CamelCase. Capitalize the first letter of a class, struct, protocol, or namespace name. Lower-case the first letter of a variable or function name. Fully capitalize acronyms. Use full words, except in the rare case where an abbreviation would be more canonical and easier to understand. """ I'm not entirely sure which category "gobj" falls in. I suspect it may be an abbreviation of g_object, in which case GObject would be how it is mapped to our naming conventions. > btw i started off with GDOM as the prefix and it blew up the pygtk > auto-generator. i posted a bugreport about that and they said that there was > absolutely zero intention of fixing pygtk's codegen.py. > > so, you _can_ go and replace Gdom with GDOM, and it will screw things up for > people, further down the line. You have used both Gdom and GDOM within the same patch. I'm also not convinced that an external, third-party tool should be dictating to our naming conventions either. I'm sure that issue is fixable within that tool or in a script that wraps the tool. > > At the very > > least this shouldn't require duplication of assignments for each possible > > feature define. The common values could be assigned to a FEATURE_DEFINES > > variable, with FEATURE_DEFINES_JAVASCRIPT taking its value and adding > > LANGUAGE_JAVASCRIPT, ENABLE_SVG, etc, and FEATURE_DEFINES_GDOM only adding > > LANGUAGE_GDOM. Another alternative would be to have FEATURE_DEFINES include > > all features that are enabled, and FEATURE_DEFINES_GDOM be the result of > > stripping out any values that mention SVG from the FEATURE_DEFINES variable. > > i _may_ be wrong about this: > > i wouldn't recommend that _at the moment_, because the person who will be > expected to create the SVG bindings in the future may choose to implement a > _small_ subset of the SVG bindings, to begin with. > > if the above paragraph translates into "when someone comes to adding SVG > bindings, then they will either have to implement them all or not at all", then > it should be clear as to why that is undesirable. I'm not sure why you think it translates to that. One way to incrementally flesh out support is to have the scripts generate code for the entire feature, but only compile the files that are completely implemented. I think we do that in some places in the Obj-C DOM in one or two places. > > > > rather than JS in the cases that they differ. Many of these instances are due > > > > to behavioral peculiarities of JS, especially attributes such as > > > > ConvertNullToNullString and toString functions. > > ConvertNullToNullString: agreed. (well, i haven't used it, and > pyjamas-desktop hasn't blown up. so i don't need it). > > toString: disagree. _definitely_ need this one. See my previous comment for why this is untrue. > > There are two issues here: the ref-counting problems tracked in bug 20403, > > which sound as though they need to be addressed before these bindings will > > function without crashing, > > no. > > 1) the crashes caused by #20403 have been demonstrated and proven to have > absolutely nothing to do with the bindings. at all. nothing. > > 2) #20403 has been solved. Ok. I was under the impression that the reason your workaround for that issue was in a previous version of the patch was that it was required in order to function. Bug 20403 does not appear to have been solved to me: Darin signed off on the concept of your fix, but some minor revisions were requested and you have yet to post the updated patch that makes them. > > and the ref-counting problems within the patch > > itself. > > there have been _no_ ref-counting problems encountered. see earlier comment: > i would be utterly shocked if there were "negative" refcounting bugs, > because of the amount of time i've spent running pyjamas-desktop apps. > > without crashes of any kind (esp. since i patched in the solution #20403) > > i would equally be surprised if there were memory leaks, but you can clearly > see, if you examine an auto-generated file, that each and every "add ref" > is matched by a corresponding "dec ref". > > so, although it's not _proven_, with test code, this "refcounting problem" > sounds much like an imaginary invention - a bogeyman in the closet :) There are problems. I called out each individually in an earlier comment, so I am not going to waste my time doing so again. The fact that you convinced the incorrect code to work does not make the code correct. The incorrect use of ref-counting absolutely must be addressed before the change can be landed. > > > 4. Changes to the IDL files. > > > > > > Any additional problems I'm missing? Could people please post their > > > thoughts on the open issues so that we can make some progress? I'll try > > > to look into issue 4 and see if I can understand what's going on, but > > > cannot promise anything for the moment. > > i wouldn't make the differences without very good reasons and justification. > > XMLHTTPRequest open(String) is a good starting point: it's simply too much > additional work to provide the functionality of TextDocument, when just > enabling the use of open(String) instead of open(TextDocument) will do just as > well, if not better. > > each of the differences is pretty obvious and straightforward, and i believe > i've answered and explained them all. You have indeed outlined why you made the changes that you did. However, as I have pointed out several times now, the reasons that you made the changes in many cases do not align with the WebKit project's vision for native bindings.

Mark Rowe (bdash)

Comment 94 2008-10-17 17:25:10 PDT

(In reply to comment #92) > > I don't think the generated bindings code should be calling ref() or deref() > > explicitly at all. Managing the lifetimes of the wrapped objects via a RefPtr > > is almost certainly sufficient. > > then why did the code crash, without them (without the ref and deref), and why > are the ObjC bindings using the ref and deref technique, which i am copying, > verbatim? The Objective-C bindings do not use RefPtr's as until relatively recently it was not valid for an Objective-C object to directly contain a non-POD C++ type. > btw i've taken a quick look at the GDOMBindings.cpp, i believe i may have > spotted an error, in the toGDOM(Element*) implementation. comparing each call > of ref(), there are a couple that are inconsistent: one calls doc->ref() which > i don't think it should. > > ... but... i copied this technique from JSBindings and ObjC bindings - why > should these bindings be different? It would seem that you have copied from both the JS bindings and the Objective-C bindings, and ended up using a mismatch of manual reference counting and automated reference counting. You should do one or the other, not both. In this case the automated approach is the best approach. Understanding how reference counting works, and how our types that automate reference counting behave, will help prevent these sorts of issues in the future.

Martín Soto

Comment 95 2008-10-20 05:21:13 PDT

(In reply to comment #94) > (In reply to comment #92) ... > > ... but... i copied this technique from JSBindings and ObjC bindings - why > > should these bindings be different? > > It would seem that you have copied from both the JS bindings and the > Objective-C bindings, and ended up using a mismatch of manual reference > counting and automated reference counting. You should do one or the other, not > both. In this case the automated approach is the best approach. Understanding > how reference counting works, and how our types that automate reference > counting behave, will help prevent these sorts of issues in the future. I'll try my hand at converting the patch to RefPtr and PassRefPtr in the following days. Unfortunately, my time is pretty limited right now, so, if someone is quicker than me at completing this task, I won't mind it, really. By the way, many thanks for the replies. The status of the patch is much clearer now.

Martín Soto

Comment 96 2008-11-30 15:30:44 PST

Created attachment 25618 [details] DOM patch updated to version 38852 So, as I said, my time is quite limited these days, but I managed to make some progress with the patch. This version is not yet ready for review, but I wanted to share it because there are some issues I'd like to discuss. First of all, what I did so far: With the previous patch, three memory blocks were being allocated to wrap a single core DOM object: the *public* structure for the wrapping GObject, the *private* structure for the wrapping GObject, and an additional C++ wrapper object. I got rid of the additional C++ wrappers altogether, which means that the private GObject structures now point directly to the core objects. I removed all classes, both generated and manually written, related to these wrapper objects. This not only helps with efficiency, but makes the patch easier to read, because the naming scheme used for the C++ wrappers made them very easy to confuse with the corresponding GObject classes. Additionally, while doing this, I refactored the code in many places to be more consistent, both in naming and behavior, with the rest of WebKitGtk. The first question I have is related to the GObject private structures. At this time, they contain only a pointer to the wrapped core object. We could also get rid of them and put this pointer directly in the main (public) wrapper GObject. The changes necessary for doing this are trivial now, and this would let us with just one allocated block per wrapped object, which would be valuable, since DOM wrappers may happen to be created in large quantities. I don't know however, what effect this may have for ABI compatibility in the future. I also started checking the use of RefPtr and friends in the patch, and I currently have an issue I don't know how to solve. In file GDOMBinding.cpp, a number of functions called toGDOM are defined that are intended to wrap core DOM objects into GObjects. Since these function actually take ownership of the references they receive, they should use PassRefPtr's as parameters. Problem is, when I change the parameters, which currently are raw pointers, to PassRefPtr, the compiler is not able to resolve the calls any more, complaining that they are ambiguous. What should I do in this case? Giving the functions different names based on the argument types doesn't look like an option, because deciding which one to call (this is mainly done by generated code) is not trivial. Any suggestions here would be greatly appreciated. Finally, I would like to rename all files, manual and generated, according to the conventions used by the rest of WebKitGtk. This is no problem, but I'm wondering about the GDOM prefix. I see no reason to have a different prefix for the DOM related objects. They belong to WebKitGTK as much as anything else, and, in my opinion, should use the same naming convention. Would people agree with this? Should I just change everything to use the WebKit (or webkit_ dpending on the case) prefix?

Luke Kenneth Casson Leighton

Comment 97 2008-12-01 02:25:52 PST

(In reply to comment #96) > Created an attachment (id=25618) [review] > DOM patch updated to version 38852 > > So, as I said, my time is quite limited these days, martin, it's great that you've taken the time to work on this. what do you think of the idea of discussing the work that you intend to carry out before going ahead, to check whether the work fits with the future plans and direction that is needed? in many cases, you would be able to guess correctly, but in others it would perhaps take up your valuable time unnecessarily, yes? > but I managed to make some > progress with the patch. great! can i ask you a favour? could you produce a diff of the diff? i.e. using the original patch as the baseline, prepare a patch with changes from the original patch into the attachment 25618 [details] patch? otherwise it's virtually impossible to follow along (which is why this 7,000 lines of complex work should be committed to webkit svn and then worked on, collaboratively, via webkit svn to fix the remaining issues). alternatively, martin, would you like to collaborate on this via a shared revision control system? i believe i've mentioned that i'm using github.org > First of all, what I did so far: With the previous patch, three memory blocks > were being allocated to wrap a single core DOM object: the *public* structure > for the wrapping GObject, the *private* structure for the wrapping GObject, and > an additional C++ wrapper object. I got rid of the additional C++ wrappers > altogether, which means that the private GObject structures now point directly > to the core objects. mmm... i made them that way to follow along with the conventions advised by various documentation and howtos that i trustingly read, but also because if there is anything _else_ that needs to be stored in the private gobject structure, the wrapper is needed. for example, at some point, the exception handling is going to be added back in (see functions in JS wrappers, they take _two_ arguments: c++ webkit obj and an exception object), and it will _not_ be added to the webkit webcore c++ objects: the only place therefore available to store and retrieve it is: the gobject private data. so - sorry to have to be the one to tell you this, but it has to stay. > but makes the patch easier to read, because the naming scheme used for the C++ > wrappers made them very easy to confuse with the corresponding GObject classes. then we pick a better one. > Additionally, while doing this, I refactored the code in many places to be more > consistent, both in naming and behavior, with the rest of WebKitGtk. great - but... the glib / gobject patch has nothing to do with and has zero dependency on WebkitGtk. > The first question I have is related to the GObject private structures. At this > time, they contain only a pointer to the wrapped core object. that's right. later they will have an exception class handling object, too. > I also started checking the use of RefPtr and friends in the patch, and I > currently have an issue I don't know how to solve. In file GDOMBinding.cpp, a > number of functions called toGDOM are defined that are intended to wrap core > DOM objects into GObjects. Since these function actually take ownership of the > references they receive, they should use PassRefPtr's as parameters. Problem > is, when I change the parameters, which currently are raw pointers, to > PassRefPtr, the compiler is not able to resolve the calls any more, complaining > that they are ambiguous. don't know - i'll have to take a look - but it will be on the code that i'm using, and used to, unless you can submit me a patch that diffs against this: http://github.com/lkcl/webkit/tree/16401.master not being funny or anything, but it's just _way_ too much work, otherwise, to be manually re-doing such massive diffs, without a common revision control system. > What should I do in this case? Giving the functions > different names based on the argument types doesn't look like an option, > because deciding which one to call (this is mainly done by generated code) is > not trivial. no, it isn't :) which is why i stopped work until someone paid me to continue. > Any suggestions here would be greatly appreciated. > > Finally, I would like to rename all files, manual and generated, according to > the conventions used by the rest of WebKitGtk. ok - two things to emphasise: first, this is a good idea, second, this patch has _nothing_ to do with WebKitGtk's functionality. this patch is a _gobject_ patch that _happens_ to be utilised, in the first instance, by WebKitGtk as the first port. other ports - the qt and the wxWidgets - are perfectly at liberty to utilise the webkit-gobject bindings, by #including <glib.h> they DO NOT i repeat DO NOT have to #include <gtk.h>. > This is no problem, but I'm > wondering about the GDOM prefix. yeah, i don't like it, either. > I see no reason to have a different prefix for > the DOM related objects. They belong to WebKitGTK no, they don't. that's why alp suggested that the functionality go into its own library - libwebkitglib.la - to strongly emphasise this. > as much as anything else, > and, in my opinion, should use the same naming convention. Would people agree > with this? Should I just change everything to use the WebKit (or webkit_ > dpending on the case) prefix? yep, i agree. _despite_ the fact that the naming convention is identical to that chosen by webkit's gtk port. it would be much better for the webkit gtk port to take a prefix of "WebkitGtk", and for the webkit-glib code to take a prefix of "Webkit".

Luke Kenneth Casson Leighton

Comment 98 2008-12-01 03:00:20 PST

> > as much as anything else, > > and, in my opinion, should use the same naming convention. Would people agree > > with this? Should I just change everything to use the WebKit (or webkit_ > > dpending on the case) prefix? > > yep, i agree. > > _despite_ the fact that the naming convention is identical to that chosen > by webkit's gtk port. > > it would be much better for the webkit gtk port to take a prefix of > "WebkitGtk", and for the webkit-glib code to take a prefix of "Webkit". for webkitmm, it looks like there isn't any choice (unless a separate library, webkitgobjectmm is created). for the same reason, webkitmm really needs to be renamed to webkitgtkmm name gdom has to go.

Martín Soto

Comment 99 2008-12-01 04:58:43 PST

(In reply to comment #97) > great! can i ask you a favour? could you produce a diff of the diff? > i.e. using the original patch as the baseline, prepare a patch with changes > from the original patch into the attachment 25618 [details] [review] patch? All patches are available from this page, you should be able to do this yourself in a minute. Am I missing something here? > alternatively, martin, would you like to collaborate on this via a shared > revision control system? > > i believe i've mentioned that i'm using github.org I would be, yes. Never used git, but I guess I can quickly learn the basics. Still, it'd be better to get this landed in some form, so that we can start contributing smaller patches. > mmm... i made them that way to follow along with the conventions advised > by various documentation and howtos that i trustingly read, but also because > if there is anything _else_ that needs to be stored in the private gobject > structure, the wrapper is needed. > > for example, at some point, the exception handling is going to be added back > in (see functions in JS wrappers, they take _two_ arguments: c++ webkit obj > and an exception object), and it will _not_ be added to the webkit webcore > c++ objects: the only place therefore available to store and retrieve it is: That's just fine. The private structures can remain if they are needed, that's why I asked before removing them. But we had a public structure, pointing to a private structure, pointing to a C++ object that finally pointed to the core object. If more data has to be stored, it can be stored in the private structure, just like the classes in GtkWebKit do. The structures are available now and have a sane, consistent naming convention. We can use them if necessary. > then we pick a better one. This is already done, and, as far as I can tell, is consistent with other classes in WebKitGtk. > the glib / gobject patch has nothing to do with and has zero dependency on > WebkitGtk. Of course, this code doesn't depend on WebKitGtk. Still, it has a lot to do with it. In particular, being also GObject based, it should follow the same or very similar coding conventions. I see no reason to depart from coding conventions that are already established and known to work. [...] > ok - two things to emphasise: first, this is a good idea, second, this patch > has _nothing_ to do with WebKitGtk's functionality. > > this patch is a _gobject_ patch that _happens_ to be utilised, in the first > instance, by WebKitGtk as the first port. > > other ports - the qt and the wxWidgets - are perfectly at liberty to utilise > the webkit-gobject bindings, by #including <glib.h> > > they DO NOT i repeat DO NOT have to #include <gtk.h>. This is all absolutely clear to me, although I'm not so sure that the Qt or WxWidgets port would like to use this; maybe the Clutter port, which is also GObject based. I agree with you that we don't want the DOM classes to depend on WebKitGtk. But we do want WebKitGtk to depend on the DOM classes in some way, and, for this reason, we should make sure that the GDOM classes follow the same conventions, whenever possible. > > This is no problem, but I'm wondering about the GDOM prefix. > > yeah, i don't like it, either. > > > I see no reason to have a different prefix for > > the DOM related objects. They belong to WebKitGTK > > no, they don't. that's why alp suggested that the functionality go into > its own library - libwebkitglib.la - to strongly emphasise this. OK, let me correct my assertion: both WebKitGtk and the GObject DOM classes are GObject-based bindings for WebKit functionallity. And they are closely related, since the GDOM classes will be used to manipulate a DOM that will often be displayed through a WebKitGtk widget. > > as much as anything else, > > and, in my opinion, should use the same naming convention. Would people agree > > with this? Should I just change everything to use the WebKit (or webkit_ > > dpending on the case) prefix? > > yep, i agree. > > _despite_ the fact that the naming convention is identical to that chosen > by webkit's gtk port. > > it would be much better for the webkit gtk port to take a prefix of > "WebkitGtk", and for the webkit-glib code to take a prefix of "Webkit". Well, I don't know to what extent it is necessary or useful to make this differenciation. I see the need for separate libraries, because other GObject-based ports, such as the Clutter port, may want to depend on the DOM classes but not on WebKitGtk. If we want all names to reflect this, I don't know, Actually, the WebKit (or webkit_) prefix refers to WebKit as a whole. given that both WebKitGTk and the DOM classes are wrapping WebKit functionality, I don't see a problem if they use the same GObject namespace.

Mark Rowe (bdash)

Comment 100 2008-12-01 09:03:32 PST

(In reply to comment #96) > Created an attachment (id=25618) [review] > I also started checking the use of RefPtr and friends in the patch, and I > currently have an issue I don't know how to solve. In file GDOMBinding.cpp, a > number of functions called toGDOM are defined that are intended to wrap core > DOM objects into GObjects. Since these function actually take ownership of the > references they receive, they should use PassRefPtr's as parameters. Problem > is, when I change the parameters, which currently are raw pointers, to > PassRefPtr, the compiler is not able to resolve the calls any more, complaining > that they are ambiguous. What should I do in this case? Giving the functions > different names based on the argument types doesn't look like an option, > because deciding which one to call (this is mainly done by generated code) is > not trivial. Any suggestions here would be greatly appreciated. Can you provide a bit more detail about what you tried here, and what errors you ran in to? There will be no need to give each variant of the function a distinct name. A simpler workaround if you can't convince the PassRefPtr approach to work would be to use a raw pointer. PassRefPtr is a matter of optimization, not correctness.

Martín Soto

Comment 101 2008-12-01 15:01:19 PST

(In reply to comment #100) > Can you provide a bit more detail about what you tried here, and what errors > you ran in to? Sure. The functions are declared as follows: gpointer toGDOM(WebCore::CSSValue* node); gpointer toGDOM(WebCore::Document* node); gpointer toGDOM(WebCore::Element* node); gpointer toGDOM(WebCore::Event* node); There are more, but you get the idea. These functions actually wrap the node object into a GObject and return it. If I change them to gpointer toGDOM(PassRefPtr<WebCore::CSSValue> node); gpointer toGDOM(PassRefPtr<WebCore::Document> node); gpointer toGDOM(PassRefPtr<WebCore::Element> node); gpointer toGDOM(PassRefPtr<WebCore::Event> node); I get error messages such as the following (this is just the first file that fails): DerivedSources/gdom/GdomAttr.cpp: In function ‘void gdom_attr__get_property_fn(GObject*, guint, GValue*, GParamSpec*)’: DerivedSources/gdom/GdomAttr.cpp:198: error: call of overloaded ‘toGDOM(WebCore::Element*)’ is ambiguous ./WebCore/bindings/gdom/GDOMBinding.h:61: note: candidates are: void* WebKit::toGDOM(WTF::PassRefPtr<WebCore::Element>) ./WebCore/bindings/gdom/GDOMBinding.h:63: note: void* WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTarget>) ./WebCore/bindings/gdom/GDOMBinding.h:64: note: void* WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTargetNode>) ./WebCore/bindings/gdom/GDOMBinding.h:66: note: void* WebKit::toGDOM(WTF::PassRefPtr<WebCore::Node>) The offending code looks as follows 197: PassRefPtr<WebCore::Element> ptr = gself->ownerElement(); 198: g_value_set_object (value, WebKit::toGDOM(ptr.get())); Line 198 fails with the messages above. When the toGDOM functions are declared with raw pointer parameters, it compiles and runs properly. > There will be no need to give each variant of the function a > distinct name. A simpler workaround if you can't convince the PassRefPtr > approach to work would be to use a raw pointer. PassRefPtr is a matter of > optimization, not correctness. Leaving the raw-pointer parameters is probably the solution, but I'm not sure if calling the toGDOM functions as shown above is the right way to do it. In particular, the local PassRefPtr variable looks suspicious to me, but it's hard for me to tell if this is OK in this particular case. I'd really appreciate some help here. By the way, should I ask these type of questions somewhere else? (IRC?, mailing list?)

Mark Rowe (bdash)

Comment 102 2008-12-01 16:05:58 PST

(In reply to comment #101) > DerivedSources/gdom/GdomAttr.cpp: In function ‘void > gdom_attr__get_property_fn(GObject*, guint, GValue*, GParamSpec*)’: > DerivedSources/gdom/GdomAttr.cpp:198: error: call of overloaded > ‘toGDOM(WebCore::Element*)’ is ambiguous > ./WebCore/bindings/gdom/GDOMBinding.h:61: note: candidates are: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::Element>) > ./WebCore/bindings/gdom/GDOMBinding.h:63: note: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTarget>) > ./WebCore/bindings/gdom/GDOMBinding.h:64: note: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTargetNode>) > ./WebCore/bindings/gdom/GDOMBinding.h:66: note: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::Node>) Ok, I can see why this would be ambiguous. Element* is implicitly convertible to each of PassRefPtr<Element>, PassRefPtr<EventTarget>, PassRefPtr<EventTargetNode>, and PassRefPtr<Node> so it's not clear which should be selected. > The offending code looks as follows > > 197: PassRefPtr<WebCore::Element> ptr = gself->ownerElement(); > 198: g_value_set_object (value, WebKit::toGDOM(ptr.get())); > > Line 198 fails with the messages above. When the toGDOM functions are declared > with raw pointer parameters, it compiles and runs properly. Calling .get() on ptr just gives you back the same underlying pointer that gself->ownerElement() returned, which would then be implicitly converted to a new PassPrefPtr instance. This would lead to the object being ref'd twice rather than once (the ref would still be balanced as the local PassRefPtr would deref when it goes out of scope). To resolve the ambiguity you could pass ptr to toGDOM rather than ptr.get();, since then no implicit type conversion will be required. However, it's probably a better idea to leave toGDOM taking a raw pointer instead. > > There will be no need to give each variant of the function a > > distinct name. A simpler workaround if you can't convince the PassRefPtr > > approach to work would be to use a raw pointer. PassRefPtr is a matter of > > optimization, not correctness. > > Leaving the raw-pointer parameters is probably the solution, but I'm not sure > if calling the toGDOM functions as shown above is the right way to do it. In > particular, the local PassRefPtr variable looks suspicious to me, but it's hard > for me to tell if this is OK in this particular case. I'd really appreciate > some help here. As I mentioned above there is a problem with the usage of PassRefPtr in the code snippet you pasted. Besides that, in existing code a local PassRefPtr is only used when storing the return value of a function returning a PassRefPtr before handing it off to a function accepting a PassRefPtr. Using it in this different manner doesn't feel quite right to me. > By the way, should I ask these type of questions somewhere else? (IRC?, mailing > list?) Both #webkit and the webkit-dev mailing list would be a reasonable place to ask this sort of question.

Luke Kenneth Casson Leighton

Comment 103 2008-12-02 01:47:38 PST

(In reply to comment #99) > (In reply to comment #97) > > great! can i ask you a favour? could you produce a diff of the diff? > > i.e. using the original patch as the baseline, prepare a patch with changes > > from the original patch into the attachment 25618 [details] [review] [review] patch? > > All patches are available from this page, you should be able to do this > yourself in a minute. Am I missing something here? yes: 1) lack of disk space 2) the inconvenience 3) we're working from different reference points. > > alternatively, martin, would you like to collaborate on this via a shared > > revision control system? > > > > i believe i've mentioned that i'm using github.org > > I would be, yes. Never used git, but I guess I can quickly learn the basics. > Still, it'd be better to get this landed in some form, ahh... slight fly in the ointment, there: "in some form" must still be "useful". as in, it must still actually do the job it's intended. at _no time_ can "in some form" _not_ provide the full functionality and satisfy all of the requirements that the code currently meets. which is why, mark, i did not provide a "dumbed-down" version. [i expect you, as a paid employee of apple, to be able to get the time to follow]. > so that we can start contributing smaller patches. xxxxing tell me about it. > > mmm... i made them that way to follow along with the conventions advised > > by various documentation and howtos that i trustingly read, but also because > > if there is anything _else_ that needs to be stored in the private gobject > > structure, the wrapper is needed. > > > > for example, at some point, the exception handling is going to be added back > > in (see functions in JS wrappers, they take _two_ arguments: c++ webkit obj > > and an exception object), and it will _not_ be added to the webkit webcore > > c++ objects: the only place therefore available to store and retrieve it is: > > That's just fine. The private structures can remain if they are needed, that's > why I asked before removing them. > But we had a public structure, a c interface where the headers are transparent. > pointing to a > private structure, the glib interface struct where the c++ object is presently stored, and in the future, the exception object will also be stored. > pointing to a C++ object that's an absolutely necessary wrapper object that contains the pure virtual function getGObjType(), and is tied in to the DOM Object cache in GDOMBinding.cpp without that pure virtual function, the whole system collapses as you cannot correctly typecast an object back to its proper c++ core object. i've explained this a number of times, but to reiterate: the issue that's faced is illustrated by the following pseudo-code: n = doc.createElement("div") n.id = "testid" body = doc.getElementsByTagName("body")[0] body.appendChild(n) not_same_n_but_it_should_be = doc.getElementByid("testid") assert(not_same_n_but_it_should_be == n) /* ERROR THROWN! */ the reason why this would fail - if you removed that "pointing to a c++ object" is because doc.getElementById() returns Node*. so, if you naively return a Node*, then a *separate* Gobject is returned - which, underneath, points to the same core c++ object (typecast down to a Node*)... ... you see where this is going? so, when the createElement() function was called, an HTMLDivElement was created, and a Gobject of type GDOM_TYPE_HTML_DIV_ELEMENT was created. this goes into the GDOMBinding DOMObject cache. > that finally pointed to the core object. i purely and simply followed, verbatim, the examples shown in the tutorials found online, and followed what was _necessary_ to provide the required functionality. correctly. so - sorry, but it has to stay as-is. this wouldn't have ended up being coded as it is without a damn good reason. > > the glib / gobject patch has nothing to do with and has zero dependency on > > WebkitGtk. > > Of course, this code doesn't depend on WebKitGtk. Still, it has a lot to do > with it. this may come as a surprise, but it has very little to do with WebKitGtk. the entry-points - the links between webkit-gdom and webkit-gtk is currently about four or five functions, and it _should_ be only one or two. > In particular, being also GObject based, it should follow the same or > very similar coding conventions. I see no reason to depart from coding > conventions that are already established and known to work. acknowledged. > [...] > > ok - two things to emphasise: first, this is a good idea, second, this patch > > has _nothing_ to do with WebKitGtk's functionality. > > > > this patch is a _gobject_ patch that _happens_ to be utilised, in the first > > instance, by WebKitGtk as the first port. > > > > other ports - the qt and the wxWidgets - are perfectly at liberty to utilise > > the webkit-gobject bindings, by #including <glib.h> > > > > they DO NOT i repeat DO NOT have to #include <gtk.h>. > > This is all absolutely clear to me, although I'm not so sure that the Qt or > WxWidgets port would like to use this; yehh... they might not - but the alternative is to go through seven kinds of hell adding yet _another_ set of bindings, bringing the total to five if QObject is used and... what does wxWidgets have - that'd be six. > maybe the Clutter port, which is also > GObject based. I agree with you that we don't want the DOM classes to depend on > WebKitGtk. But we do want WebKitGtk to depend on the DOM classes in some way, yes. the dependency can be reduced to about two functions and two glib-based objects. a glib wrapper around a pointer to the virtual base class WebCore::Page (let's call it WebkitWebPage) and another one around WebCore::Frame (which already exists in gdom); WebkitWebFrame should have a pointer to a GdomFrame, and should take in a pointer to a WebkitWebPage as well. in this way, it's possible for other ports - qt and wxwidgets - to create their own WebkitWebPage and their own GdomFrame, set up the links between the two, and you're done. it's not "QObject-y". it's not "wxWidget-y". but it works, and those ports could then replace the functionality, at their leisure, with QObject-y DOM bindings and wxWidget-y DOM bindings. > and, for this reason, we should make sure that the GDOM classes follow the same > conventions, whenever possible. yes. ... what are they? > > > This is no problem, but I'm wondering about the GDOM prefix. > > > > yeah, i don't like it, either. > > > > > I see no reason to have a different prefix for > > > the DOM related objects. They belong to WebKitGTK > > > > no, they don't. that's why alp suggested that the functionality go into > > its own library - libwebkitglib.la - to strongly emphasise this. > > OK, let me correct my assertion: both WebKitGtk and the GObject DOM classes are > GObject-based bindings for WebKit functionallity. And they are closely related, > since the GDOM classes will be used to manipulate a DOM that will often be > displayed through a WebKitGtk widget. i should reiterate: the sole link is via one function. once you have a pointer to what is now called "GdomDocument", WebkitGtk's role is OVER. finished. oh. other than event handling. so, there's an event link (i gave it a signal name of "browser-event") and there's a way to get a GdomDocument. NOTHING else. sure, things like window.open() might get called, and things like window.alert(), or other such interaction... but it's NOT "triggered" by gtk, or by any gtk interaction, and not by any gtk functions, and not by any WebkitGtk functionality. gtk's role is _extremely_ limited to some _very_ specific roles that have, other than the passing in and out of a pointer to a Frame, a Page, a Document and some event handling, absolutely nothing to do with the webkit-glib DOM bindings. > > > as much as anything else, > > > and, in my opinion, should use the same naming convention. Would people agree > > > with this? Should I just change everything to use the WebKit (or webkit_ > > > dpending on the case) prefix? > > > > yep, i agree. > > > > _despite_ the fact that the naming convention is identical to that chosen > > by webkit's gtk port. > > > > it would be much better for the webkit gtk port to take a prefix of > > "WebkitGtk", and for the webkit-glib code to take a prefix of "Webkit". > > Well, I don't know to what extent it is necessary or useful to make this > differenciation. I see the need for separate libraries, because other > GObject-based ports, such as the Clutter port, may want to depend on the DOM > classes but not on WebKitGtk. If we want all names to reflect this, I don't > know, Actually, the WebKit (or webkit_) prefix refers to WebKit as a whole. yes, and as such, webkit/gtk is causing inconvenience, having "taken over" that namespace. pywebkitgtk does the same thing - it's called itself "webkit" not "webkitgtk" or "gtk.webkit". > given that both WebKitGTk and the DOM classes are wrapping WebKit > functionality, I don't see a problem if they use the same GObject namespace. ack.

Luke Kenneth Casson Leighton

Comment 104 2008-12-02 01:59:04 PST

(In reply to comment #101) > (In reply to comment #100) > > Can you provide a bit more detail about what you tried here, and what errors > > you ran in to? > > Sure. The functions are declared as follows: > > gpointer toGDOM(WebCore::CSSValue* node); > gpointer toGDOM(WebCore::Document* node); > gpointer toGDOM(WebCore::Element* node); > gpointer toGDOM(WebCore::Event* node); > > There are more, but you get the idea. These functions actually wrap the node > object into a GObject and return it. If I change them to > > gpointer toGDOM(PassRefPtr<WebCore::CSSValue> node); > gpointer toGDOM(PassRefPtr<WebCore::Document> node); > gpointer toGDOM(PassRefPtr<WebCore::Element> node); > gpointer toGDOM(PassRefPtr<WebCore::Event> node); > > I get error messages such as the following (this is just the first file that > fails): > > DerivedSources/gdom/GdomAttr.cpp: In function �void > gdom_attr__get_property_fn(GObject*, guint, GValue*, GParamSpec*)�: > DerivedSources/gdom/GdomAttr.cpp:198: error: call of overloaded > �toGDOM(WebCore::Element*)� is ambiguous > ./WebCore/bindings/gdom/GDOMBinding.h:61: note: candidates are: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::Element>) > ./WebCore/bindings/gdom/GDOMBinding.h:63: note: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTarget>) > ./WebCore/bindings/gdom/GDOMBinding.h:64: note: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::EventTargetNode>) > ./WebCore/bindings/gdom/GDOMBinding.h:66: note: void* > WebKit::toGDOM(WTF::PassRefPtr<WebCore::Node>) > > The offending code looks as follows > > 197: PassRefPtr<WebCore::Element> ptr = gself->ownerElement(); > 198: g_value_set_object (value, WebKit::toGDOM(ptr.get())); this is exactly what the javascript code does. the pointer is stored in a RefPtr<WebCore::Element> in the "internal" c++ class that has GDOMObject as its base: a private member called m_impl. perhaps the solution to satisfy mark's concerns is as simple a matter of removing the calls to ref() and deref() - i'll see what effect that has. the calls to ref() and deref() were added from copying the style of the ObjC bindings DOMObject cacheing.

Mark Rowe (bdash)

Comment 105 2008-12-02 02:25:10 PST

(In reply to comment #104) > > The offending code looks as follows > > > > 197: PassRefPtr<WebCore::Element> ptr = gself->ownerElement(); > > 198: g_value_set_object (value, WebKit::toGDOM(ptr.get())); > > this is exactly what the javascript code does. > > the pointer is stored in a RefPtr<WebCore::Element> in the "internal" > c++ class that has GDOMObject as its base: a private member called m_impl. The JavaScript bindings do not create a local PassRefPtr to pass in to toJS, as the code quoted above does. What you describe relates to how the wrapper holds the reference to the wrapped object. Holding it as a RefPtr is indeed what the JavaScript bindings do, and what most (all?) bindings layers should do. The Objective-C bindings don't do this for historical reasons. > perhaps the solution to satisfy mark's concerns is as simple a matter of > removing the calls to ref() and deref() - i'll see what effect that has. Using ref() and deref() manually without a specific need to do so is a good indication that reference counting is being handled incorrectly. The latest iteration of the patch still appears to have problems in this area. One part of the patch doesn't quite make sense to me: what is the relationship between the generated "_${className}Private" structures and _GdomDOMObjectPrivate? They both contain members named coreObject, but only the former uses a RefPtr for this purpose. This seems as though it could lead to confusion. > the calls to ref() and deref() were added from copying the style of > the ObjC bindings DOMObject cacheing. The Objective-C bindings manually ref and deref raw pointers because their existence predates compiler support for storing non-POD C++ objects as members of Objective-C classes. The compiler has since grown support for this feature, but we've not had a chance to update the Obj-C DOM bindings to use RefPtrs.

Luke Kenneth Casson Leighton

Comment 106 2008-12-02 02:38:08 PST

(In reply to comment #105) > > the pointer is stored in a RefPtr<WebCore::Element> in the "internal" > > c++ class that has GDOMObject as its base: a private member called m_impl. > > The JavaScript bindings do not create a local PassRefPtr to pass in to toJS, as > the code quoted above does. well... i didn't want to admit this, because i really _do_ want to encourage martin's involvement, but as things stand i've not been able to merge in your contributions, martin, because, due to the size of the patch, finding them is too time-consuming. so, i'm still using http://github.com/lkcl/webkit/tree/16401.master the reason i mention that, mark, is because i'm still working with toGDOM(WebCore::{insertclassname}*) - as is done in the JSBindings. > What you describe relates to how the wrapper holds the reference to the wrapped > object. Holding it as a RefPtr is indeed what the JavaScript bindings do, and > what most (all?) bindings layers should do. The Objective-C bindings don't do > this for historical reasons. ok - well, i've removed the manual calls to ref() and unref() and there doesn't appear to be any collateral damage. > > perhaps the solution to satisfy mark's concerns is as simple a matter of > > removing the calls to ref() and deref() - i'll see what effect that has. > > Using ref() and deref() manually without a specific need to do so is a good > indication that reference counting is being handled incorrectly. The latest > iteration of the patch still appears to have problems in this area. i had corrected the ref and unrefs to match up - however, given that the gdom private c++ objects (all those that derive from GDOMObject) all have a RefPtr to the underlying webcore c++ object, it looks like the ref() and unref() calls are completely unnecessary. and your descriptions of the way things work - and of the historical objc workings - would seem to bear that out. > One part of the patch doesn't quite make sense to me: what is the relationship > between the generated "_${className}Private" structures and > _GdomDOMObjectPrivate? They both contain members named coreObject, but only > the former uses a RefPtr for this purpose. This seems as though it could lead > to confusion. lemme take a look and get back to you. thx.

Mark Rowe (bdash)

Comment 107 2008-12-02 02:40:13 PST

(In reply to comment #106) > the reason i mention that, mark, is because i'm still working with > toGDOM(WebCore::{insertclassname}*) - as is done in the JSBindings. If you'd bothered to read my previous comment (comment #102) you'll see that is exactly the approach that I recommended be used.

Martín Soto

Comment 108 2008-12-02 03:33:24 PST

(In reply to comment #103) > that's an absolutely necessary wrapper object that contains the > pure virtual function getGObjType(), and is tied in to the > DOM Object cache in GDOMBinding.cpp > > without that pure virtual function, the whole system collapses as > you cannot correctly typecast an object back to its proper c++ > core object. Let me address only this point because I have to leave in a few minutes. I read your comments in the code about the "absolutely necessary getGObjType() virtual method", and spent quite some time checking all code paths were it was involved. It turns out that this method returns exactly the same GObject type that is stored in the wrapping GObject. After checking the code quite thoroughly, I found that, in practice, all getGObjType() was being used for, was to carry information from the top of the toGDOM functions to the bottom of those same functions. I changed the toGDOM functions to wrap the core objects into GObjects right from the start, and so I could get rid of getGObjType() alltogether. Just look at the relevant portions (you surely know were to find them, no need to compare) or, even better, run it. It runs here for sure, so certainly getGObjType() was not so absolutely necessary.

Luke Kenneth Casson Leighton

Comment 109 2008-12-02 03:41:56 PST

i did.(In reply to comment #107) > (In reply to comment #106) > > the reason i mention that, mark, is because i'm still working with > > toGDOM(WebCore::{insertclassname}*) - as is done in the JSBindings. > > If you'd bothered to read my previous comment (comment #102) i did. > you'll see that is > exactly the approach that I recommended be used. this is a complex area which is difficult to understand: even with the (simple) fix of removing ref() and unref() and even in the evidence of an (empirical) test not blowing up, i still don't fully get why it doesn't fall over. so, your explanations have helped to bring about a tentative experiment that has succeeded - and you should be proud of that rather, than critical. please stick to our agreement of six or so weeks ago, it will make everyone's lives easier.

Luke Kenneth Casson Leighton

Comment 110 2008-12-02 04:11:22 PST

(In reply to comment #108) > (In reply to comment #103) > > that's an absolutely necessary wrapper object that contains the > > pure virtual function getGObjType(), and is tied in to the > > DOM Object cache in GDOMBinding.cpp > > > > without that pure virtual function, the whole system collapses as > > you cannot correctly typecast an object back to its proper c++ > > core object. > > Let me address only this point because I have to leave in a few minutes. ok - well, these archives are forever - they're not going away, they'll be here when you're back :) > I read > your comments in the code about the "absolutely necessary getGObjType() virtual > method", and spent quite some time checking all code paths were it was > involved. It turns out that this method returns exactly the same GObject type > that is stored in the wrapping GObject. ah... ah... um... if it _exists_ yet. > After checking the code quite > thoroughly, I found that, in practice, all getGObjType() was being used for, > was to carry information from the top of the toGDOM functions to the bottom of > those same functions. I changed the toGDOM functions to wrap the core objects > into GObjects right from the start, and so I could get rid of getGObjType() > alltogether. if that works, in both the usage cases, i'll genuinely be dead impressed. it's been so damn long i wish this hadn't been left for so damn long, because i'm struggling to remember the two usage cases. the first is clear: there are, what... 150 or more "new" object instantiations through GDOMBinding.cpp and from there in many cases to GDOMHTMLElementWrapperFactory.cpp (all of which you've replaced with wrapXxxxXxxx functions). the code path that particularly has me concerned is the one where the object is NOT in the cache, and DOM.getElementById("..."), DOM.getElementsByTagName(...) etc. are used. the WebCore c++ functions return a Node*. the object is _actually_ an (e.g.) HTMLDivElement*, and GDOMBindings.cpp goes to a hell of a lot of switch statement trouble to make damn sure that the right gobject is created. you know what? i think you're right - i think it's those switch statements that do the correct work. _great_. > Just look at the relevant portions (you surely know were to find them, no need > to compare) or, even better, run it. *freaks out slightly* :) > It runs here for sure, so certainly > getGObjType() was not so absolutely necessary. i'll find out soon enough and get back to you.

Luke Kenneth Casson Leighton

Comment 111 2008-12-02 04:25:05 PST

(In reply to comment #106) > > One part of the patch doesn't quite make sense to me: what is the relationship > > between the generated "_${className}Private" structures and > > _GdomDOMObjectPrivate? They both contain members named coreObject, but only > > the former uses a RefPtr for this purpose. ahh, not quite: a closer look shows that the _GdomDOMObjectPrivate struct contains an internal gdom class; _${className}Private contains a WebCore::{className}. so the purposes are different. i'm _hoping_ that martin's work means that _GdomDOMObjectPrivate can go away, as the _${className}Private might be able to, as well. will let you know once i've overcome my fear of creating another branch in the git repository.

Luke Kenneth Casson Leighton

Comment 112 2008-12-02 07:39:03 PST

martin - i've just started looking at the patch you created, and i can't use it and test it because there is critical functionality missing. specifically: it's missing the toString calls, which are absolutely essential for the project i'm working on (pyjamas-desktop) to actually be useful to anyone. i'll have to add them back in, and i will supply two patches: one for everyone else, and one specifically for you (so you can add them in on top of what you already have). i know why you removed them. mark: i realise that you're is advocating that certain functionality is "not to be used", unfortunately, the justification is at best unreasonable and at worst flawed. if there was no "legacy" of javascript's expected functionality, you would be at liberty to dictate the progress and functionality. however, given that users coming from the javascript environment are going to expect certain functions to exist WITH ABSOLUTELY NO REGARD WHATSOEVER FOR WHATEVER STANDARDS MAY OR MAY NOT EXIST, you cannot unfortunately tell one group of developers "yes if you use javascript it's ok, you can have functions like toString" and then turn round and say to another group of developers "no, you're not allowed that, even though you're used to that functionality and blatant disregard for the W3C standards". the glib gdom bindings are not the place to "fight" for w3c standardisation. if you want the glib gdom bindings, and all other bindings, to not have a toString function or anything else that's not in the W3C standards, take it up with every single javascript developer in the world and get them to stop using those functions and the functionality that's not in the standards. take it up with microsoft, firefox, the developers of opera, and, most importantly, get it removed from webkit's javascript bindings. we both know that's not going to happen, but the reason i mention it is to illustrate that it's unreasonable to make the glib / gdom bindings "suffer" because a particular standard has been over-ruled by a real world one. that _also_ having been said: Gecko / XUL has toString, and offers it to the language bindings. bottom line: you really _can't_ tell the glib / gdom bindings that they MUST rigidly adhere to an "unreal" standard.

Luke Kenneth Casson Leighton

Comment 113 2008-12-02 07:56:25 PST

(In reply to comment #109) > i did.(In reply to comment #107) > > (In reply to comment #106) > > > the reason i mention that, mark, is because i'm still working with > > > toGDOM(WebCore::{insertclassname}*) - as is done in the JSBindings. > > > > If you'd bothered to read my previous comment (comment #102) > > i did. additionally, whilst i appreciate that it's really frustrating to have so much to deal with, with this patch - keeping its functionality useable and stable _and_ complete _and_ fixing the issues - there is a solution which would help solve the frustration of having to look every single time through such a large patch, having to look every single time for answers in amongst so many comments, and it's this: you land the patch. as-is. no questions. no quibbles. no ifs. no buts. _then_ you - and i - and everyone else - submits _small_ individual patches that deal with the remaining issues. each individual issue is then isolated, and can be discussed conveniently. alternatively, we continue this excruciatingly awkward process where approximately... twenty separate and distinct technical issues are dealt with in over 110 messages that nobody really wants to search through to keep up-to-date. in other words, we need a bugtracker and a revision control system because apple won't let us use the existing bugtracker and revision control system. if apple won't let us use the existing bugtracker and revision control system, then apple can't complain when things get frustrating and unwieldy, can they?

Luke Kenneth Casson Leighton

Comment 114 2008-12-02 08:56:03 PST

(In reply to comment #110) > > After checking the code quite > > thoroughly, I found that, in practice, all getGObjType() was being used for, > > was to carry information from the top of the toGDOM functions to the bottom of > > those same functions. I changed the toGDOM functions to wrap the core objects > > into GObjects right from the start, and so I could get rid of getGObjType() > > alltogether. > > if that works, in both the usage cases, i'll genuinely be dead impressed. martin, you're a genius: it worked. main_frame = self._browser.get_main_frame() set_main_frame(main_frame) gdoc = main_frame.get_gdom_document() body = gdoc.get_elements_by_tag_name("body").item(0) h = gdoc.create_element("div") h.append_child(gdoc.create_text_node("hello world")) body.append_child(h) h.set_attribute('id', "hello world") h1 = gdoc.get_element_by_id("hello world") print h, h1 h == h1. success. so - that leaves toString to be added back in; ref() and deref() to be removed (which i tested earlier and will test again); that should be everything.

Luke Kenneth Casson Leighton

Comment 115 2008-12-02 09:10:31 PST

Created attachment 25671 [details] patch for martin to add martin, this is for you to add on top of what you already have, to reintroduce the toString, Location and getSelection that you left out. i'm not sure about the Window properties yet (described as "constructors"). they may prove useful.

Luke Kenneth Casson Leighton

Comment 116 2008-12-15 03:40:50 PST

Created attachment 26025 [details] add gdom_event_target_node_dispatch_event() this function is necessary in order to be able to simulate events, like this: doc = webkit_web_frame_get_dom_window(frame); mouseevent = dom_document_create_event(doc, "MouseEvent"); gdom_mouse_event_init_mouse_event (mouseevent, gchar * type, gboolean can_bubble, gboolean cancelable, GdomDOMWindow * view, glong detail, glong screen_x, glong screen_y, glong client_x, glong client_y, gboolean ctrl_key, gboolean alt_key, gboolean shift_key, gboolean meta_key, gushort button, GdomEventTargetNode * related_target); and finally: gdom_event_target_node_dispatch_event(doc, mouseevent) to actually send off the event as if a real mouse event had occurred.

Luke Kenneth Casson Leighton

Comment 117 2008-12-31 07:52:27 PST

(In reply to comment #91) > (In reply to comment #88) > > (In reply to comment #87) > > > #if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > > > [DontEnum] DOMString toString(); > > > #endif > > > > > > toString() is also a JavaScript language concept that other bindings need to > > > worry about. > > > > i do keep explaining - but it's been a while so i will explain it again: > > javascript is the language that i am targetting as providing _direct_ > > one-for-one, concept-for-concept, function-for-function, class-for-class, > > attribute-for-attribute equivalence (as closely as possible). > > In that case, your objective is not the same as the objectives of the DOM > bindings in WebKit. As I have stated, they are designed to wrap the standard > WebKit DOM, and only to expose quirks to JavaScript where they are required for > compatibility with other browsers. and, logically by extension, webkit being a browser engine, all applications _based_ on webkit thus being browsers, "quirks to Javascript" must be "exposed" without fail and without exception on _all_ bindings, such that all applications work from the same "standard". even if it's a damn stupid one that's dictated by real-world stupidity rather than a clean design from W3C. > The DOM is not JavaScript. i'm fully aware of that. however, that has nothing to do with the DOM _standard_ being over-ridden by IE5, IE6, IE7, IE8, Firefox, Mozilla all getting that DOM standard completely wrong, thus forcing the DOM standard - as viewed through the eyes of Javascript Bindings - to be subtly different. > I don't think the argument that a developer expects > to see JavaScript semantics from a non-JavaScript DOM binding holds much > weight. well the fact that you don't see that means that the pyjamas-desktop project must be terminated, as there is absolutely zero point in proceeding to use webkit (the best and currently only reasonable and viable option to providing python bindings to a fully-functioning DOM model). so - thank you: the fact that you are unable to see that means that apple is responsible for destroying the progress of free software development. > We've had no complaints of this nature, about the Objective-C DOM > bindings in the many years that they have been part of the project. i would consider that to be an indication that no serious objective-c DOM project has ever been developed - certainly not one that covers almost 100% of the functionality of the DOM model. the pyjamas-desktop project covers quite literally absolutely every corner of the DOM model: when porting pyjamas to pyqt4, that failed because of limitations in pyqt4. when porting it to pygtk2, that failed even quicker, due to more significant limitations. when porting it to python-pykde, _that_ turned out to have really subtle limitations (c++ RTTI has been disabled, and the equivalent of the HashMap in JSBindings.cpp and GDOMBindings.cpp utterly relies on RTT) and so _that_ port failed as well. due to the nature of what pyjamas-desktop is, it squeezes every corner of its underlying technology until the pips squeak. > > the same thing goes for the "constructors" (if i can get my head round why > > they're used). > > Are you seriously arguing that you must have something that you don't > understand? The JavaScript constructors are used only for gaining access to > the prototype object, a JavaScript concept, which simply does not make sense > for other DOM bindings. > > > the same thing also goes for the suggestion that you made that i should > > provide only "integer" input to setWidth() and other functions, because that's > > what ObjC does. > > > > the answer's "no - absolutely not". people who expect to pass in "3em", > > "10px", "50%" will get a nasty shock. > > As I have already stated, people that try and set .width or .height "3em" will > already get a nasty shock, even from JavaScript. It does not do what you think > that it does. i don't care! if they get a nasty shock from javascript, and they then get the _same_ nasty shock from the gobject bindings _great_. bug-for-bug. feature-for-feature. nasty-shock-for-nasty-shock. as the guardians of webkit, it's not our job to "care" what happens. > > and yes, i really really _do_ need toString() because it's actually _used_ in > > the pyjamas-desktop DOM.py module. > > This argument doesn't carry much weight, as it could be used to get *any* > change in to WebKit. i don't know how to respond to this. you seem unable to accept reasonable real-world usage as justification for providing specific functionality, without which the project i'm working on - the only example and _the_ leading free software example - is dead. gecko's language bindings provide toString. python-pykde, KHTMLPart's language bindings provide toString. webkit's javascript language bindings provide toString. why are you "dictating" that the webkit gobject bindings should _not_ have toString, when you are being _specifically_ told that a project _needs_ that functionality? > It can be generalised to: "I've written some code in > another project that depends on my work-in-progress patch, therefore you have > to accept this change in to WebKit in order to not break that code." it's not about "breaking" that code - that "code" is DEAD without it. > All of the objects that provide a .toString() function to JavaScript there are > native DOM methods to return the same data. so what? > Applications using the native DOM > bindings can simply use the appropriate methods to retrieve this information. so, i must write some code, "if in pyjamas-desktop, the library being used equals webkit, and the object does not have a toString function, then detect what type it is and then from there work out the quotes appropriate method quotes' else if the library being used is python-gecko, call the toString function, else if the library is python-pykde, call the toString function". not going to happen. please ask the gecko developers to remove toString from their language bindings, and see how far you get. please also ask the KDE KHTML developers to remove toString from their language bindings, and see how far you get. > > remember, i'm translating the javascript (by hand, unfortunately) in pyjamas > > into DIRECT and IDENTICAL function calls (in python) that end up calling the > > webkit-glib bindings. > > > > if i get *any* discrepancies (such as not having toString), then all of a > > sudden i'm screwed, because there's a difference between the pyjamas code > > (javascript compiler) and the pyjamas-desktop code (webkit-based). > > I think you need to keep in mind that DOM bindings in WebKit do not exist > solely for the benefit of your project. i'm well aware of that. > Your project, as the first user of the > DOM bindings, certainly influences what the initial cut will support, but it in > no way defines what they *must* support. mark. you are being dictatorial, unreasonable, and deliberately obstructive. why do you _care_ whether there is a toString function that some NONEXISTENT projects may or may not use, ESPECIALLY when the ONLY project - that obviously happens to be the first - is TELLING you it needs that function, and is TELLING you that all OTHER language bindings provide that function? why do you _care_ about _deliberately_ sticking to the W3C DOM standards, when you're being told that to do so will result in failure of a project? is there something that you're not telling us? are you being _paid_ or being instructed by your employer to be deliberately obstructive, and to delay or otherwise scupper the usefulness of the gobject DOM bindings? because that's the only possible explanation that i can think of that makes any sense. the other possibility is that you're being obstructive just for the sake of it, to gain some feeling of power or something. instead of dictating what should or should not be in the gobject bindings, which you have _no_ experience of using and the use of which is _not_ in your area of expertise, you should be encouraging this first project that uses them to be successful, as the leader and pathfinder. i am perfectly happy to listen to your advise and to learn from your expertise in the inner workings of webkit - your expertise and knowledge of the ref-counting and other technical areas has been absolutely invaluable, and in many other areas as well. however, for you to respond to reasonable justification for specific features with "that could be a justification to put _anything_ into webkit" is completely unprofessional. it's called "moving the goalposts", so that you "win". you want to "win" - and be a bully while you're at it. i'm sorry to have to be pointing these things out - i really wish i didn't have to be the one to draw these conclusions. but anyone reviewing these records will be able to draw the same conclusions, and likewise wonder why you're being unreasonably obstructive. l.

Luke Kenneth Casson Leighton

Comment 118 2008-12-31 13:53:01 PST

mark, hi, after reviewing and reading what HTMLAppletElement and HTMLEmbedElement are, they are fairly low-priority HTML elements, and so the impact of them being int or strings is minimal. the reason why i had been so insistent that they be kept - according to the de-facto standard that is "javascript" - is because i thought for quite some time that these were offsetWidth and offsetHeight, of HTMLElement! so, my case for insisting that the de-facto javascript standard be followed, even though users will shoot themselves in the foot by doing so, still applies - and even though we've been talking somewhat at cross-purposes (for which i apologise) - _but_, given that it's _not_ HTMLElement (thank god) that you're talking about, but two specific low-key elements, i don't care enough about those to press the point. the number of developers using DOM bindings on those elements is going to be pretty small. so - who cares. toString is a different matter. the algorithm that you describe - namely to identify those elements where toString is offered, followed by identifying the alternate functions - i know of a place where that algorithm is already implemented... ... it's in a project called... WEBKIT. making every single developer who uses webkit bindings (and expects toString to exist) _reimplement_ the functionality that _already_ exists is... petty at best. i can continue to think of lots of ways to say this: none of them really get us anywhere, and leave us both wasting time that would be better spent developing code and serving users.

Gustavo Noronha (kov)

Comment 119 2008-12-31 14:12:41 PST

> however, for you to respond to reasonable justification for specific features > with "that could be a justification to put _anything_ into webkit" is > completely unprofessional. I disagree, and I believe it is you who is being unprofessional. I, too, believe your rationale could be used to put anything into webkit. I could write a personal project today which wanted to use a completely insane and non-standard way of handling javascript calls and do just like you are doing, even yelling in (repeated) sentences like you do: 'a project which already exist is TELLING you they NEED it'. So what if my project needs it? So what if pyjamas-desktop needs it? We need to figure out if it is the correct and best way of doing things for WebKit and the bulk of its users, not for your own pet project. I also feel you are being very unprofessional by implying all the time that the bindings you are pushing are a real project, while the Objective-C bindings must be a simple toy (and you have been doing that with other parts of the work, too). The Objective-C bindings exist far longer, and have been used for much longer, and in more projects, so I can't see how you came to the conclusion that they are toyish. > i'm sorry to have to be pointing these things out - i really wish i didn't > have to be the one to draw these conclusions. but anyone reviewing these > records will be able to draw the same conclusions, and likewise wonder why > you're being unreasonably obstructive. I draw the exact opposite conclusions. Why are _you_ being so unreasonable? I, for one, am against doing anything to the GObject DOM bindings that deviates from the standard. Where we deviate from the standard, it should be because we're following a proven de-facto standard, to keep compatibility, not because your personal project needs it, so stop invoking your project as a parameter, pretty please.

Luke Kenneth Casson Leighton

Comment 120 2009-01-01 05:33:37 PST

gustavo, i do not know who you are, and so i let your unhelpful comments slide, the first time (#78). now i cannot ignore them. mark and i made an agreement to keep to technical issues - however, unfortunately, there have been an increasing number of personal accusations and unprofessional non-technical comments made as "justifications" for blocking technical and strategic progress, and i cannot any longer keep silent by ignoring them. your comments are as unhelpful to the professional development and progress of webkit glib dom bindings as mark's comments have been (except for the technical advice comments he's been giving, which have been incredibly helpful and valuable, and have helped the development and progress of the webkit glib bindings enormously). i will point out these things and then we will move on. > So what if my project needs it? So what if pyjamas-desktop needs it? We need to > figure out if it is the correct and best way of doing things for WebKit and the > bulk of its users, not for your own pet project. the description of the only full and complete project which uses the webkit glib dom bindings as "my own pet project" is as insulting and unhelpful as when mark also referred to it as "my own pet project". i think it would be a good idea for you to publicly apologise for making an accusation that i indulge in "pet projects". also: where are the "other users"? tell me where the "other users of webkit glib / dom bindings" are? in essence what you're saying is that pyjamas-desktop is "not worth respecting". it is "nothing". what you are saying is that, having worked on the glib / dom bindings, you are going to wait for _another_ project to come along (not pyjamas-desktop) and you are going to listen to and respect them enormously, and follow _their_ lead, _their_ advice... ... but not any advice or experience that comes from me. is that right? > I also feel you are being very unprofessional by implying all the time that the > bindings you are pushing are a real project, ... and you're saying that the bindings are not??? (no of course you're not - but it just reads that way) > while the Objective-C bindings must be a simple toy to draw that conclusion is faulty logic. i said "i doubt whether any projects that use the objective-c bindings hammer those bindings - make as _full_ use of them - as pyjd makes use of the glib/gobject bindings". i anticipate that someone with more experience than i in the objective-c bindings will correct me, specifically in the areas of the usage of "to string" conversion of elements, and in the areas of functionality of HTMLAppletElement and HTMLEmbedElement, specifically the width and height properties. in the three short weeks in which i developed the webkit-glib bindings, due to the nature of what pyjamas-desktop is and does, pyjamas-desktop pushed pretty much _every_ single button there is to push in webkit. what other webkit-related projects do you know of that do that? more to the point, what other webkit-related projects have you - personally - got _specific_ and _direct_ experience with, that involve the glib / dom bindings _and_ absolutely hammer the stuffing out of the webkit-glib API? > (and you have been doing that with other parts of the > work, too). i'm sorry to hear that you were able to draw that perception. > The Objective-C bindings exist far longer, and have been used for to give you a specific example: when i ported pyjamas-desktop onto pykhtml / pykde, in under _six hours_ i encountered a very subtle bug that has been present in KDE's python KHTMLPart bindings that has been there for a _long_ time. nobody - not _anyone_ - not even the developer of PyKHTML (see http://paul.giannaros.org/pykhtml/) had spotted the bug. as pyjd is effectively a widget set API, it _hammers_ the underlying DOM model technology like you would not (and clearly do not) believe. > much longer, and in more projects, so I can't see how you came to the > conclusion that they are toyish. i'm sorry to hear that you perceived that i have drawn this conclusion. please consider correcting any impression that i have insulted and disrespected the webkit developers by implying that i consider such incredibly valuable work to be "a toy". the objective-c bindings were an absolutely invaluable guiding light in the development of the glib bindings, and i have an enormous amount of respect for the technical ability of the developers who wrote that code. if i did not have so much respect for their code, there is no way that i would have been able to have written the glib bindings in such an incredibly short amount of time. i would have been spending my time "objecting" to various absolutely critical design decisions. > > i'm sorry to have to be pointing these things out - i really wish i didn't > > have to be the one to draw these conclusions. but anyone reviewing these > > records will be able to draw the same conclusions, and likewise wonder why > > you're being unreasonably obstructive. > > I draw the exact opposite conclusions. Why are _you_ being so unreasonable? let's look at the word "un"-reasonable. i have given "good reasoned" - reasonable - arguments for following the lead of javascript, as a de-facto standard, rather than following one which people _try_ to stick to (W3C) - and often fail. those arguments have been ignored - and, instead of putting "reasoned" and "reasonable" support for the dictats given, "un"-reasoned "unreasonable" and logically unsupportable arguments have been given instead, such as the one that you also support. i am left somewhat amazed. > I, for one, am against doing anything to the GObject DOM bindings that deviates > from the standard. Where we deviate from the standard, it should be because > we're following a proven de-facto standard, hooray! i absolutely whole-heartedly agree with you! _fantastic_! now. here's the thing. the javascript bindings are a de-facto standard. if you believe otherwise, please explain, providing examples and reasonable justification, as to why you believe that the JS bindings are not a de-facto standard. if you agree with me that the javascript bindings are a de-facto standard, please state so clearly. > to keep compatibility, hooray! yes! exactly! well done! > not because > your personal project needs it, so stop invoking your project as a parameter, > pretty please. once again, i have to point out several things: 1) describing pyjamas-desktop as a "my personal project" is insulting. you will work out best how to apologise for saying so. 2) as the javascript bindings are a de-facto standard, and pyjamas-desktop is a port of a javascript compiler which utilises javascript DOM bindings and utilises pretty every single damn function and feature _of_ the javascript DOM bindings, it is simple logic which leads me to be advocating that the glib DOM bindings should support exactly the same functionality: pyjamas uses JS DOM ---> firefox, IE, safari provide JS DOM bindings pyjd uses Glib DOM ---> XUL, PyKHTML, webkit provide ... wait..... webkit _doesn't_ provide full DOM bindings, because mark rowe and gustavo norono silva have absolutely no respect for my opinion and expertise, believe that i am indulging in "pet projecting", thus dismissing out-of-hand the entire project and are going to "wait until someone else comes along with a quotes non-pet quotes project". in other words, gustavo norona silva, you don't trust me, and you have no respect for my work. ... do you? 3) any use of a sentence which has the words "pretty please" in it, between people who have _zero_ prior context or conversational interaction, is wildly inappropriate for a technical forum. ESPECIALLY one which will be a permanent record of the development of a strategically important free software project such as this one. so. let's draw some conclusions, and let's rewrite what you've written, justavo, so that it is more appropriate, and then i will respond to that. > > however, for you to respond to reasonable justification for specific features > > with "that could be a justification to put _anything_ into webkit" is > > completely unprofessional. > luke, i do not know who you are, and i have never spoken to you before, > but the way that you are coming across does unfortunately look as > unprofessional as you are saying that mark is being. i trust that you > have good reasons for saying what you are, but surely there must be > better ways to say it? gustavo, thank you for responding - yes it's most unfortunate that this highly strategically important free software opportunity is fast becoming a bun-fight with an apple employee. i realise that i'm not entirely at ease, sometimes, with communication of highly technical issues: it often takes several rounds for me to get it right, and i have had financial pressures to deal with that haven't helped my frame of mind. i apologise for this, and trust that you will make allowances. yes there are very good reasons for pressing this point, and i seem to be making a bit of a hash of explaining them. it doesn't help that mark's attitude is an adversarial one, where he is working to "knock down" rather than "cooperate". it's this that is what i regard as unprofessional on his part, especially as an employee and representative of the billion-dollar corporation called "apple". if i appear unprofessional, myself, it's because i am reacting out of surprise, being completely caught off-guard at being treated so badly. > regarding your rationale, i have to agree with mark that it _does_ > look as if it could be used to "put anything into webkit" as mark > unfortunately puts it, and i would welcome a clarification from you > on this. it certainly looks, on the face of things, like you are > seeking the addition of a non-standard way to handle javascript calls, > and if that is the case then mark is perfectly justified, in my > opinion, in ensuring that that does not happen. ah - i'm glad that you raised this, because it is most certainly _not_ the case that i am looking to "extend" the bindings "beyond" what _existing_ de-facto standards already provide. if you look beyond the shouting, you will see that "toString" and also the properties of HTMLEmbedElement and HTMLAppletElement are part of a "de-facto" javascript standard which has been "forced" onto webkit's JS bindings, against apple's will. my take on this is that once something is "forced" into the de-facto Javascript bindings standard, it's really too late: it must _become_ part of that de-facto standard, and thus must become part of other language bindings at all. all or not at all. and given that "not at all" is not possible, it must be "all". to do otherwise is... well... you think of a word to describe it, because i can't think of one that mark is willing to accept. >So what if my project needs it? So what if pyjamas-desktop needs it? We need to >figure out if it is the correct and best way of doing things for WebKit and the >bulk of its users, not for your own pet project. > in saying tha "pyjamas desktop needs it", unfortunately you haven't > clearly said _why_ pyjamas-desktop needs these features. either that, > or i am misunderstanding something, for which i apologise. > We need to figure out if it is the correct and best way of doing things > for WebKit and the bulk of its users, as well as for the project that > you're working on. pyjamas-desktop and the invaluable work you've done > in adding python bindings to the DOM model in pywebkitgtk is the only > example that uses the webkit-glib dom bindings _right now_ but we need > to think ahead. yes, i absolutely agree with you - and that's exactly the perspective from which i have been thinking. i did not think it necessary to emphasise this, as i considered that, given that glib/gobject has multiple language bindings autogenerators it would be implicit.... you get what i'm trying to say, i hope - but i apologise for not being clear. again, the real key here is in the fact that the javascript DOM features make the javascript bindings an over-riding de-facto standard, and i believe that it would be a serious mistake to attempt to make the W3C standard the "lead". pyjamas-desktop is just the one [and currently the only] example where, if you do _not_ have webkit's glib DOM bindings be as identical as possible to the webkit JS bindings, then pyjamas-desktop becomes _very_ very awkward if not impossible to do. however i do appreciate that it is _only_ an example, but to ignore that example, instead of learning from the difficulties it has encountered, _does_ strike me as being a little bit... odd. surely, other projects (which don't yet exist!) should be learning from this, and going, "hmmm.... that's really interesting - we should be watching out for that, and making sure that apple _don't_ push the W3C standards over-and-above the de-facto Javascript standard, because we might run into the same difficulties that this guy lkcl is describing that his obscure project we've never heard of is running into". .... gosh, this is taking up an enormous amount of my time. i'm going to leave it there, and i trust that you can see what i am trying to do by rewriting what you've said, and i trust that you can see how much easier it is to answer things in the rewritten style. no longer do i have to tiresomely "counteract" every single statement and sentence that you make (except the one about javascript being a de-facto standard! :) instead i can focus on clarification of my points, and can clear up any misunderstandings, and, through successive iterations we work _together_ on the glib bindings, instead of working _against_ each other. yes? i will leave it up to you as to whether you would like to continue the rewrite, following the far-less-inflammatory style - one which leaves an opening and an opportunity for discussion, rather than one which i would not expect to come from an experienced free software developer with an "@gnome.org" email address.

Luke Kenneth Casson Leighton

Comment 121 2009-01-01 06:38:13 PST

IHTMLStyle.toString: http://msdn.microsoft.com/en-us/library/aa768820(VS.85).aspx IDOMTextNode.toString: http://msdn.microsoft.com/en-us/library/aa704073(VS.85).aspx IHTMLElement.toString: http://msdn.microsoft.com/en-us/library/aa752332(VS.85).aspx IHTMLElementCollection.toString: http://msdn.microsoft.com/en-us/library/aa703933(VS.85).aspx IHTMLSelectElement.toString: listed in wine-dev's mshtml.idl file - so we know it exists - but it's not actually listed in the msdn online documentation. IHTMLSelectElement has _five_ extensions (1-5 _and_ an Ex!) so it doesn't surprise me that the docs are out-of-date. IOmNavigatorElement.toString: http://msdn.microsoft.com/en-us/library/aa703735(VS.85).aspx IHTMLLocation.toString: http://msdn.microsoft.com/en-us/library/aa703648(VS.85).aspx IHTMLWindow2.toString: http://msdn.microsoft.com/en-us/library/aa741504(VS.85).aspx IHTMLDocument2.toString: http://msdn.microsoft.com/en-us/library/aa752636(VS.85).aspx IHTMLCommentElement.toString: exists in wine-dev mshtml.idl so we know it exists but it is not listed in the msdn documentation.

Luke Kenneth Casson Leighton

Comment 122 2009-01-01 06:49:53 PST

Luke Kenneth Casson Leighton

Comment 123 2009-01-01 07:12:41 PST

example useage of PyKDE's KHTMLPart document.toString() function: http://www.mail-archive.com/pyqt@riverbankcomputing.com/msg09577.html unfortunately, the discussion centres around how the function causes a segfault! but the documentation on Document.toString's existence, in the KDE HTML DOM model bindings, is here: http://developer.kde.org/documentation/library/3.3-api/khtml/html/classDOM_1_1Document.html hmmm.. that seems a bit out-of-date, here's a more up-to-date one: http://api.kde.org/3.5-api/kdelibs-apidocs/khtml/html/classDOM_1_1Document.html#fa3edf3819e0dc6ccf120e5e5d462ccf there's also a kde 4.x and a kde 4.1 version. there is however also a toHTML() function in DOMNode, which is listed as "deprecated" - presumably someone decided that calling toString "toHTML" was a bad idea. ah! finally! i found a by-function-name reference: http://api.kde.org/4.0-api/kdelibs-apidocs/khtml/html/functions_0x74.html which shows that the two occurrences of toString() are in DOM::Document and DOM::Range: http://api.kde.org/4.0-api/kdelibs-apidocs/khtml/html/classDOM_1_1Range.html#2358111339856f9a61bf0456d03daf3a also, it looks like DOM::Node.toHTML _didn't_ get deprecated, after all, and is still there: http://api.kde.org/4.x-api/kdelibs-apidocs/khtml/html/classDOM_1_1Node.html#249840ef6631b425d7ced51397545b32 so, overall, KDE's KHTMLPart interface has a limited supply of "toString" functions [which make it a far-from-ideal candidate as a target for pyjd but that's another story] but it _does_ actually _have_ the most important toString functions - the ones for DOM::Document and DOM::Range.

Luke Kenneth Casson Leighton

Comment 124 2009-01-01 07:19:56 PST

from the quoted references to "toString" which can clearly be shown to exist in all the major browser engines - not specifically limited to "javascript" but to all the major browser engines' generic language bindings - it can be concluded that leaving out "toString" because it "isn't in the W3C specification" would be a serious mistake. that, given the prevalent support for "toString" in all other competitor products to webkit, users of webkit DOM bindings _would_ find it irritatingly odd that "toString" is missing. i have to be honest with you, i was a bit surprised to find that IE's MSHTML.idl definition file supports it! :) wine's reverse-engineered version of mshtml.idl is here: http://source.winehq.org/source/include/mshtml.idl this illustrates why i have been advocating that javascript's bindings should be the guiding light. i trust that i no longer have to go through such extreme lengths to demonstrate the case for javascript's de-facto standard being authoritative over the W3C "non-real-world" standard. there are over 300 objects, 1500 functions and tens of thousands of properties, and that's _without_ the SVG canvas bindings and without having enabled HTML5 video support (which i haven't tried yet). to have to go through "justifying" every single difference would be tedious in the extreme.

Luke Kenneth Casson Leighton

Comment 125 2009-01-01 07:36:48 PST

http://msdn.microsoft.com/en-us/library/aa703907(VS.85).aspx HRESULT IHTMLEmbedElement::get_width(VARIANT *p); HRESULT IHTMLEmbedElement::put_width(VARIANT v); Parameters p Pointer to a variable of type VARIANT of type VT_I4 or VT_BSTR that receives one of the values listed in Possible Values. v VARIANT of type VT_I4 or VT_BSTR that specifies one of the values listed in Possible Values. Possible Values width Integer that specifies the width of the object in pixels. percentage Not applicable to C++. Return Value Remarks This property is an integer value. Although an HTML author can specify the width as a percentage, this property always specifies the width in pixels in C++. oh look! in IE, they have encountered exactly the same pain as webkit, and chose to deal with it by allowing IHTMLEmbedElement.width to be set to _either_ a string _or_ an integer. i won't go through all of the properties for IE's HTMLEmbedElement and HTMLAppletElement - i'm wasting enough time on this as it is.

Luke Kenneth Casson Leighton

Comment 126 2009-01-01 07:39:41 PST

KDE's HTMLAppletElement setHSpace(DOMString &string) function: http://api.kde.org/4.0-api/kdelibs-apidocs/khtml/html/classDOM_1_1HTMLAppletElement.html#8b2abf2ea0476bb40af513232240f107 KDE's HTMLAppletElement setHSpace(long value) function: http://api.kde.org/4.0-api/kdelibs-apidocs/khtml/html/classDOM_1_1HTMLAppletElement.html#3c84c8400913f971db4c58a87a99e2c5 again - KDE supports _both_ long _and_ string setting for hspace. vspace is the same. KDE does not appear to _have_ an HTMLEmbedElement (either that or i can't find it) - i presume that embedding is done in some alternative KDE-specific way: KHTMLPart is after all an "embedded" part, itself.

Luke Kenneth Casson Leighton

Comment 127 2009-01-01 07:46:11 PST

Documentation for XUL's HTMLAppletElement: http://www.xulplanet.com/references/objref/HTMLAppletElement.html interesting. hspace and vspace are PRInt32s. Documentation for HTMLEmbedElement: http://www.xulplanet.com/references/objref/HTMLEmbedElement.html even _more_ interesting: width and height are String properties. no information is given on exactly what values are supported in these strings.

Adam Dingle

Comment 128 2009-02-10 20:12:44 PST

Created attachment 27549 [details] DOM patch with lots of fixes, updated to revision 40813 My colleague Jim and I are highly interested in seeing DOM bindings added to WebKit/GTK. Over the last couple of weeks, we've extensively cleaned up and enhanced the last patch posted here (posted by Martin Soto in comment #96 on 11/30) in an effort to resolve all outstanding issues. Here is a list of the major changes we've made, followed by a list of potentially open questions. - We've updated the patch to build with a current WebKit (revision 40813, corresponding to the latest nightly build). - In the last patch, each wrapper GObject pointed to a private structure which in turn pointed to a native C++ WebKit object. (Comments on this thread show that there was previously yet one more level of indirection which Martin has already removed.) These pointers were duplicated at each level of the inheritance hierarchy. For example, a GdomHTMLButtonElement pointed to a native HTMLButtonElement, but the parent class GdomHTMLElement and all other parent classes also contained pointers to the native object. This was unnecessary and wasteful. With our changes, each wrapper GObject simply contains an opaque void * which actually points to the native C++ object. We've eliminated the duplicate pointers in the inheritance hierarchy as well as the private structure. Comments in this thread indicate that the private structure was created in case we might need to store extra data there in some future version of the code. We doubt that will be necessary, but if we do need a private structure at some point we can simply update the void * to point to it without breaking binary compatibility with applications that use DOM objects. Because we've eliminated the private structure, we can't use a C++ smart pointer to point to the native C++ object, and so we call ref() manually when a GObject wrapper is initialized and call deref() when it's finalized. As some reviewers pointed out, the existing code called ref() on some smart pointers in some cases, which was unnecessary; we've eliminated that wherever it happened in the code. - The W3C DOM specifies that certain methods may raise exceptions. In the last patch, DOM exceptions were not made available in any way to an application using the GObject wrapper layer. The usual way to report errors in GObject is through a parameter of type GError ** at the end of a method's parameter list. (In fact, Vala's bindings generator can automatically generate exceptions in Vala when calling a GObject method that takes a GError **). With our changes, whenever a DOM method raises an exception, the corresponding GObject method has a GError **. If an exception occurs, the returned GError contains a textual description of the error as reported by the DOM code. - In the last patch, each DOM attribute was exposed as a GObject property, but not via GObject getter/setter methods. In GTK it's actually common to expose properties in both ways; for example, GTKWidget has both a "name" property and methods gtk_widget_get_name() and gtk_widget_set_name(). We feel that GObject properties alone are inadequate for exposing DOM attributes, both because they are relatively inefficient (they are accessed via a string name provided at runtime) and also because there's no way to report error information when a caller gets or sets a property. With our changes, each DOM attribute is exposed both as a property and via getter/setter methods. When the DOM specifies that getting or setting the attribute may raise an exception, the corresponding getter/setter method takes a GError ** for error reporting. We're not particularly attached to using GObject properties at all, and can remove them if you like; that would significantly reduce code size (especially in the generated code). It's up to you. - The last patch contained some support for reporting DOM events to the GObject caller. The event interface was different from that specified by the DOM and the implementation was incomplete (there was no way to unregister an event listener). In our patch we've removed all the event code, simply because events raise various design issues and we'd prefer to deal with them in a subsequent iteration. As various commenters have mentioned, the patch is large enough as it is and removing the event code seemed like a good way to reduce its size. - We've eliminated IDL changes which caused the GObject binding to behave like JavaScript in some special cases. All GObject calls now behave like the static Objective-C binding. - gdom.h previously included a large hard-coded list of files; we now autogenerate this. The makefiles also included large hard-coded lists of GObject wrapper sources; these are now generated dynamically (just like the lists of JObject wrapper sources to be built). - By removing events, autogenerating file lists and performing miscellaneous code cleanup we've reduced the size of the patch from over 5500 lines to under 3500 lines. - We've eliminated the separate defines FEATURE_DEFINES_GDOM and FEATURE_DEFINES_JAVASCRIPT in the makefiles. - With the last patch, header files were installed in two places: in include/webkit-1.0/gdom and in include/webkit-1.0/webkit. We now install them only in include/webkit-1.0/gdom. - Where possible, we've renamed source and header files to have all-lowercase names as is conventional in GTK. The autogenerated wrapper files still have CamelCase names because we use implicit makefile rules to generate these from .idl files, which also have CamelCase names, and GNU make doesn't allow us to perform a lowercasing transformation inside the implicit the rule. So the autogenerated filenames don't quite fit the GTK convention; we don't think this is a significant problem. - The last patch included a function named GStringConvert; this name didn't fit the coding conventions. We've renamed it to gdom_gstring_convert(). - There were some lines of the form #include "gdom/xxx.h". We've changed these to look like #include "xxx.h"; the makefiles now include the gdom directory in the include path if necessary. - Some #includes used angle brackets unnecessarily as pointed out by Alp in comment 28; we've fixed this. - The Apple copyright lacked the text "All rights reserved" in some source files; we've fixed this. - The Perl generator script contained lots of tabs; we've replaced them with spaces. == open questions == Here are design decisions that potentially remain open along with their current status. We're happy to change any of these in the code to satisfy the consensus of the WebKit team. 1. How should GObject DOM classes be named? To represent the DOM interface called Element, we could use any of the following: GdomElement (the current choice); GDOMElement; WebKitElement; WebKitDOMElement. We don't have a strong opinion here. It's slightly unusual for a single GTK package to contain classes with two different prefixes, and so if we use the Gdom or GDOM prefix we'll need to play some tricks in order to autogenerate Vala bindings for the webkit-1.0 package, which will contain some classes prefixed with WebKit (e.g. WebKitWebFrame) and others prefixed with Gdom/GDOM. (We've actually done this, and can share our Vala bindings generator script if you like.) If we use names such as WebKitElement or WebKitDOMElement then Vala bindings should be automatic. If we use WebKitElement without the word DOM, then API documentation which shows a sorted list of classes will show DOM classes interspersed with other WebKit classes; this might be confusing. On the other hand, the WebKitDOM prefix will lead to long names such as WebKitDOMHTMLBlockquoteElement. If we use either the Gdom, GDOM or WebKitDOM prefix we might want to remove duplicate occurrences of the word DOM; for example, we could replace GdomDOMObject with GdomObject. We have not done this at this point. 2. Should a DOM attribute be exposed both via getter/setter methods and via a property, or only via getter/setter methods? As mentioned above, we currently have both getters/setters and properties but are willing to take the property code away if desired. 3. How does a string returned by a DOM function get freed? Currently the caller is responsible for freeing. In comment 28 Alp suggested other possible mechanisms such as some sort of garbage collection. We believe that the existing caller-frees policy is the way to go; it is the usual mechanism in GObject classes and will play well with higher-level language bindings. === We're looking forward to having these bindings in WebKit! Please let me know if there's anything more we can do to help out.

Mark Rowe (bdash)

Comment 129 2009-02-10 22:29:01 PST

Adam, thanks for taking the time to work on this feature. Hopefully some of those working on the GTK port API (Christian, Xan, Holger?) can comment on the API aspects of this patch. I'll try and find time to look over the patch myself later this week.

Xan Lopez

Comment 130 2009-02-11 01:20:00 PST

(In reply to comment #128) Hi, thanks for picking up this! > == open questions == > > Here are design decisions that potentially remain open along with their current > status. �We're happy to change any of these in the code to satisfy the > consensus of the WebKit team. > > 1. How should GObject DOM classes be named? �To represent the DOM interface > called Element, we could use any of the following: �GdomElement (the current > choice); GDOMElement; WebKitElement; WebKitDOMElement. > > We don't have a strong opinion here. �It's slightly unusual for a single GTK > package to contain classes with two different prefixes, and so if we use the > Gdom or GDOM prefix we'll need to play some tricks in order to autogenerate > Vala bindings for the webkit-1.0 package, which will contain some classes > prefixed with WebKit (e.g. WebKitWebFrame) and others prefixed with Gdom/GDOM. > �(We've actually done this, and can share our Vala bindings generator script if > you like.) > > If we use names such as�WebKitElement or WebKitDOMElement�then Vala bindings > should be automatic. �If we use WebKitElement without the word DOM, then API > documentation which shows a sorted list of classes will show DOM classes > interspersed with other WebKit classes; this might be confusing. �On the other > hand, the WebKitDOM prefix will lead to long names such as > WebKitDOMHTMLBlockquoteElement. > > If we use either the Gdom, GDOM or WebKitDOM prefix we might want to remove > duplicate occurrences of the word DOM; for example, we could replace > GdomDOMObject with GdomObject. �We have not done this at this point. When this has come up before I've said that I prefer consistency and making life easier for bindings in general, even if the price to pay is longer type names for C hackers. IMHO C/GObject hackers are already used to boilerplate and complexity that is only there for the benefit of the bindings, and they usually solve this with macros and code completion :) > > 2. Should a DOM attribute be exposed both via getter/setter methods and via a > property, or only via getter/setter methods? �As mentioned above, we currently > have both getters/setters and properties but are willing to take the property > code away if desired. I think we should have both. AFAIK explicit getter/setter methods predate the property system, and are only retained for compatibility and performance reasons, but I'm pretty sure many bindings will construct their getter/setters from the property directly, maybe overriding them with the direct access functions IF they exist (this is what the Java bindings do IIRC), or providing both the same way C does. Also properties have other benefits, like notify functions, mass set/get, etc. > > 3. How does a string returned by a DOM function get freed? �Currently the > caller is responsible for freeing. �In comment 28 Alp suggested other possible > mechanisms such as some sort of garbage collection. �We believe that the > existing caller-frees policy is the way to go; it is the usual mechanism in > GObject classes and will play well with higher-level language bindings. Completely agree. Anything else would probably be a nightmare for bindings. > > === > > We're looking forward to having these bindings in WebKit! Please let me know > if there's anything more we can do to help out. > Some small nitpicks from the patch, style issues: You are using NULL all over the place, I think '0' is preferred for stuff that goes into WebCore/ (we use, or try to use, NULL for C-ish files that go into WebKit/gtk/ though...) +gpointer GDOMObjectCache::getDOMObject(void* objectHandle) +{ + gpointer ret = domObjects().get(objectHandle); + return ret; +} No need for the variable. +gpointer toGDOM(HTMLCollection* collection) +{ + if (!collection) + return NULL; (...) Is it a valid usage of the function to pass NULL? If not you should use g_return_val_if_fail() IMHO. - The g_dom_string_convert methods seems pretty generic, maybe you could change the gdom_ prefix for something else?

Xan Lopez

Comment 131 2009-02-11 02:21:08 PST

(In reply to comment #128) > Created an attachment (id=27549) [review] > - In the last patch, each DOM attribute was exposed as a GObject property, but > not via GObject getter/setter methods. In GTK it's actually common to expose > properties in both ways; for example, GTKWidget has both a "name" property and > methods gtk_widget_get_name() and gtk_widget_set_name(). �We feel that GObject > properties alone are inadequate for exposing DOM attributes, both because they > are relatively inefficient (they are accessed via a string name provided at > runtime) and also because there's no way to report error information when a > caller gets or sets a property. BTW, one way of dealing with this would be to add a property to the base class of the DOM objects that would hold the error, so you could do something like g_object_get (object, "dom-property", &dom, "dom-error", &error, NULL); I guess you'd define it so that it only holds the first error reported, to match the semantics of exceptions (meaning that if you try to access several properties at the same time you'll only get the first error in case there's several..). Of course setter/getter functions are easier because you can only access one property at a time :)

Luke Kenneth Casson Leighton

Comment 132 2009-02-11 04:14:52 PST

(In reply to comment #128) > Created an attachment (id=27549) [review] > DOM patch with lots of fixes, updated to revision 40813 > > My colleague Jim and I are highly interested in seeing DOM bindings added to > WebKit/GTK. fantastic! > - We've updated the patch to build with a current WebKit (revision 40813, > corresponding to the latest nightly build). great! > - In the last patch, each wrapper GObject pointed to a private structure which > in turn pointed to a native C++ WebKit object. (Comments on this thread show > that there was previously yet one more level of indirection which Martin has > already removed.) These pointers were duplicated at each level of the > inheritance hierarchy. For example, a GdomHTMLButtonElement pointed to a > native HTMLButtonElement, but the parent class GdomHTMLElement and all other > parent classes also contained pointers to the native object. This was > unnecessary and wasteful. yehh, but it worked, and got everyone who was interested in glib/gobject bindings "from here to there" :) > With our changes, each wrapper GObject simply contains an opaque void * which > actually points to the native C++ object. We've eliminated the duplicate > pointers in the inheritance hierarchy as well as the private structure. > Comments in this thread indicate that the private structure was created in > case no, not "in case", it WILL be necessary. as i did not understand at the time what "exec" was for, i removed all instances - several thousand - where the "exec"ution context was being used. it is NECESSARY not "a nice lovely optional idea" to have a pointer to the exception context. > we might WILL, not might. > need to store extra data there in some future version of the > code. > We doubt that will be necessary, i cannot help you with your doubt. perhaps if you say "would someone be kind enough to explain" then perhaps mark, myself or alp will help put you right. > but if we do need a private structure > at some point we can simply update the void * to point to it without breaking > binary compatibility with applications that use DOM objects. great. > Because we've eliminated the private structure, we can't use a C++ smart > pointer to point to the native C++ object, and so we call ref() manually when a > GObject wrapper is initialized and call deref() when it's finalized. ahh... the use of ref() and deref() were a key reason why the existing patch was not accepted. mark cited "use of ref() and deref() typically indicate broken code and/or broken design". > As some > reviewers pointed out, the existing code called ref() on some smart pointers in > some cases, which was unnecessary; we've eliminated that wherever it happened > in the code. good luck :) > - The W3C DOM specifies that certain methods may raise exceptions. In the last > patch, DOM exceptions were not made available in any way to an application > using the GObject wrapper layer. that's correct. that's why there was the "exec" argument, propagated literally thousands of times, which i removed (not understanding what it was for, and looking to simplify the initial work). the javascript bindings choose to store this pointer to exec in the private struct. > The usual way to report errors in GObject is > through a parameter of type GError ** at the end of a method's parameter list. ahh, thank you. > (In fact, Vala's bindings generator can automatically generate exceptions in > Vala when calling a GObject method that takes a GError **). With our changes, > whenever a DOM method raises an exception, the corresponding GObject method has > a GError **. If an exception occurs, the returned GError contains a textual > description of the error as reported by the DOM code. hmm, i wonder how python-pygobject does it. > - In the last patch, each DOM attribute was exposed as a GObject property, but > not via GObject getter/setter methods. really? oh. i thought i had added everything. oh well. > With our changes, each DOM attribute is exposed both as a property and via > getter/setter methods. great! oo, that would be much better. > When the DOM specifies that getting or setting the > attribute may raise an exception, the corresponding getter/setter method takes > a GError ** for error reporting. We're not particularly attached to using > GObject properties at all, and can remove them if you like; that would > significantly reduce code size (especially in the generated code). It's up to > you. so that the VALA bindings and the PYTHON bindings can provide exact concept-for-concept functionality as the de-facto JAVASCRIPT standard as well as the W3C DOM standard, it would make sense to ensure that, given that the DOM raises exceptions, also therefore, gobject should raise exceptions, yes? > - The last patch contained some support for reporting DOM events to the GObject > caller. yes. event handling is absolutely essential for the gobject bindings to be useful. * using the python-bindings-to-gobject-bindings, every single event type without exception and without fail is captured and processed by the "event preview" method, and much more. * when the mouse goes outside of the window, there are instances where it can be detected that, unless you manually generate a specific mouse event, then when the mouse returns into the window, your state machine and your application will be utterly confused. so not only is it necessary to have event handling but also it is necessary to have event _generation_. for example event generation would allow developers to create emulated keyboards and emulated mouse / touchscreen devices - written in VALA or PYTHON (not javascript) or plain c (using the gobject bindings, direct). receipt of mouse and/or keyboard events from the device of their choice (such as a wii remote) > The event interface was different from that specified by the DOM and > the implementation was incomplete (there was no way to unregister an event > listener). In our patch we've removed all the event code, simply because > events raise various design issues and we'd prefer to deal with them in a > subsequent iteration. which unfortunately makes the patch useless for anyone who wishes to generate or listen to events. as you noticed with the much-duplicated-pointers "broken" design, a "broken" design which provides specific functionality, even if it's in a "broken design" way, is _much_ more useful than something that just... throws out a whole stack of options because it's not "perfect", yes? with a "broken" design, at least people can carry on using the patch, even though it's "broken", and can help _contribute_. if you've ripped out that entire functionality, i cannot help you easily, to contribute to this patch, because i would first have to understand what you've done, and _then_ add back in the event handling... > As various commenters have mentioned, the patch is large > enough as it is and removing the event code seemed like a good way to reduce > its size. the patch provides specific functionality - a complete and comprehensive set of functionality - that matches the W3C and the de-facto JAVASCRIPT standard functionality. without _every_ single one of the features, the patch is utterly useless. so you've implemented all but 1% of the W3C standard and the de-facto JAVASCRIPT standard. thus, anyone who needs that last 1% is... screwed. > - We've eliminated IDL changes which caused the GObject binding to behave like > JavaScript in some special cases. All GObject calls now behave like the static > Objective-C binding. as pointed out, this is an execptionally bad idea. what you are doing is getting the gobject bindings to conform to the strict W3C standard instead of to the de-facto JAVASCRIPT standard. the static Objective-C bindings are the _only_ bindings in the world that conform to the strict W3C standard. actually, as the Objective-C bindings also provide things that are on the IE6 list, that are specifically mentioned in the W3C standard as being supported only by IE, contrary to the W3C standard, they don't even do that. examples of such include offset-width. offset-width is NOT a W3C standard, it is a de-facto standard. by the logic being dictated, here, offset-width must be REMOVED from webkit, yes? no. because it's _useful_. it's part of the de-facto standard, now. i went to a lot of trouble to highlight that _every single one_ of those modifications has corresponding equivalents in the competitor products to webkit. MSHTML. KHTMLPart. Gecko. they all provide the de-facto standard bindings as shown in the original patch. indicating that it's actually the objective-c bindings that are borked. > - gdom.h previously included a large hard-coded list of files; we now > autogenerate this. hoooraaay! :) > The makefiles also included large hard-coded lists of > GObject wrapper sources; these are now generated dynamically (just like the > lists of JObject wrapper sources to be built). yessss, brilliant :) > - By removing events, if i say "that's not good", you understand that that's an understatement of the first order, yes? > autogenerating file lists and performing miscellaneous > code cleanup we've reduced the size of the patch from over 5500 lines to under > 3500 lines. excellent. > - We've eliminated the separate defines FEATURE_DEFINES_GDOM and > FEATURE_DEFINES_JAVASCRIPT in the makefiles. that's also not good. > - With the last patch, header files were installed in two places: in > include/webkit-1.0/gdom and in include/webkit-1.0/webkit. We now install them > only in include/webkit-1.0/gdom. *thinks*.... that's probaby a good idea. > - Where possible, we've renamed source and header files to have all-lowercase > names as is conventional in GTK. The autogenerated wrapper files still have > CamelCase names because we use implicit makefile rules to generate these from > .idl files, which also have CamelCase names, and GNU make doesn't allow us to > perform a lowercasing transformation inside the implicit the rule. So the > autogenerated filenames don't quite fit the GTK convention; we don't think this > is a significant problem. likewise. it also simplifies the code auto-generation process. > - The last patch included a function named GStringConvert; this name didn't fit > the coding conventions. We've renamed it to gdom_gstring_convert(). it is an "internal" function. its purpose has nothing to do with gobject. to make that clear, i gave it UpperCase naming. you would do well to rename it back to a more suitable UpperCase naming, picking one that is more suited to WebKit c++ coding conventions than glib / gobject ones. the function should NOT be utilised or exposed as part of the gobject glib gdom bindings. i repeat. it is a PRIVATE and INTERNAL function. > - There were some lines of the form #include "gdom/xxx.h". We've changed these > to look like #include "xxx.h"; the makefiles now include the gdom directory in > the include path if necessary. _great_ > - Some #includes used angle brackets unnecessarily as pointed out by Alp in > comment 28; we've fixed this. _great_. > - The Apple copyright lacked the text "All rights reserved" in some source > files; we've fixed this. > > - The Perl generator script contained lots of tabs; we've replaced them with > spaces. i'm not a perl hacker :) > == open questions == > > Here are design decisions that potentially remain open along with their current > status. We're happy to change any of these in the code to satisfy the > consensus of the WebKit team. > > 1. How should GObject DOM classes be named? To represent the DOM interface > called Element, we could use any of the following: > GdomElement (the current choice); fine. > GDOMElement; do not do this. stick to SingleCapitalLetters. the python-pygobject bindings auto-generator goes horribly horribly wrong if you have MULTIPLECapitalLetters. i've spoken to the developers of python-pygobject: they are aware of the issue and, given that it is a convention to have SingleCapitalLetters they have ABSOLUTELY NO INTENTION of supporting MULTIPLECapitalLetters. the reason cited is that the code in python-pygobject is complex enough as it is without having to support non-standard conventions. > WebKitElement; fine. also already discussed with martin, who believes that it is a good choice. although it overlaps the gtk-utilised namespace (e.g. WebKitWebFrame) there's never really going to be a clash, thanks to the prefix _actually_ being "WebKitWeb" not just "WebKit". > WebKitDOMElement. WebKitDomElement is fine, MultipleCAPITALLetters is not. starting to get a bit long, though. not that that matters when it comes to auto-generated code / bindings: an extra step can always be added to rip off the unnecessary prefix, in the VALA bindings and PYTHON bindings. > We don't have a strong opinion here. It's slightly unusual for a single GTK > package to contain classes with two different prefixes, and so if we use the > Gdom or GDOM prefix we'll need to play some tricks in order to autogenerate > Vala bindings for the webkit-1.0 package, which will contain some classes > prefixed with WebKit (e.g. WebKitWebFrame) and others prefixed with Gdom/GDOM. > (We've actually done this, and can share our Vala bindings generator script if > you like.) yes please, that would be fantastic. > If we use names such as WebKitElement or WebKitDOMElement then Vala bindings > should be automatic. If we use WebKitElement without the word DOM, then API > documentation which shows a sorted list of classes will show DOM classes > interspersed with other WebKit classes; this might be confusing. On the other > hand, the WebKitDOM prefix will lead to long names such as > WebKitDOMHTMLBlockquoteElement. > > If we use either the Gdom, fine. > GDOM _definitely_ don't do this. > or WebKitDOM will cause problems. > prefix we might want to remove > duplicate occurrences of the word DOM; for example, we could replace > GdomDOMObject with GdomObject. We have not done this at this point. not recommended. it will then be hard to both conceptually and coding-wise map between the two. and all auto-generators will have unnecessary complications, not just the CodeGeneratorGobject.pm but everyone else, too. > 2. Should a DOM attribute be exposed both via getter/setter methods and via a > property, or only via getter/setter methods? As mentioned above, we currently > have both getters/setters and properties but are willing to take the property > code away if desired. i recommend leaving both in. python-pygobject, the gobject-to-python autogenerator, is _much_ happier when using the getter/setter method, as it exposes the properties via a dictionary interface on the python object that's bound to the gobject object. _removing_ the getters/setters and properties would make life fricking awkward. and, worse, would then make the bindings non-conformant i.e. they would no longer "look like" the javascript equivalents. i.e. this in javascript: if (node.offsetwidth > 10) { .... } can translate into: if node.offsetwidth > 10: .... whereas _without_ the getter/setter properties, it would have to be: if node.get_offset_width() > 10: .... which would be.... ugly as hell. and if you wanted to _make_ a getter/setter interface, you can't, because you don't have a convenient list of properties available. overall, removal of the getter/setter properties xxxxs everything up. > 3. How does a string returned by a DOM function get freed? Currently the > caller is responsible for freeing. yes. this is the standard gobject convention: caller responsible for freeing. python-pygobject happily auto-generates code that conforms to the gobject convention. > In comment 28 Alp suggested other possible > mechanisms such as some sort of garbage collection. We believe that the > existing caller-frees policy is the way to go; it is the usual mechanism in > GObject classes and will play well with higher-level language bindings. agreed. > === > > We're looking forward to having these bindings in WebKit! lots of people are :) > Please let me know > if there's anything more we can do to help out. thank you - i will take you literally at your word, there, and dive right in: * conforming to the de-facto standards rather than the absolute to-the-letter W3C standards, which _nobody_ actually sticks to (not even webkit), would be very helpful. * adding back in the event handling, which i know you removed for what you believed were good reasons [you could have contacted me and asked my advice], would be very helpful. * picking a CamelCase prefix instead of a CAPITALISEDATTHEFront prefix would be very helpful. martin and i both agreed that "WebKit" would be a perfectly reasonable and acceptable prefix. * keeping the getter/setter properties would be very helpful. i think those are the main things. overall i'm absolutely delighted that you've chosen to help out with the webkit glib bindings. i do have to point out however - and i trust that you will take this at face value - that by following the strict W3C standard rather than the de-facto javascript standard you are expressing a lack of experience and a lack of _comprehensive_ knowledge of DOM usage and DOM-based application development. do not take that personally: it's a clear and simple fact that can logically deduced from the patch that you've submitted. actually, it's not quite true: you _may_ have comprehensive and significant experience of DOM usage and DOM-based application development, but if so, you're not using it as part of the VALA bindings on top of the submitted gobject patch. it is clear that the application that you are developing in VALA is not yet a significantly comprehensive one. the lack of event handling is particularly key to being able to deduce this. * the VALA application cannot set up responders / event / preview callbacks to resize, load, mouse and keyboard events. * the VALA application cannot handle AJAX asynchronous events, which is a _real_ significant omission. * the VALA application cannot "create" events - or, it can _create_ them, but cannot "fire them" into the infrastructure. there is a good reason why the SUGAR team dropped webkit and went with Gecko to create Hulahop, and that's because, although completely undocumented, the language/generic-interface bindings to Gecko are comprehensive, complete, and conform to the de-facto standards. the point i'm making is that if you would like to help, you would do well to help ensure that the webkit glib / gobject bindings conform to ALL the relevant de-facto standards, thus making them useful to a much wider cross-developer base.

Luke Kenneth Casson Leighton

Comment 133 2009-02-11 04:21:07 PST

(In reply to comment #131) > (In reply to comment #128) > > Created an attachment (id=27549) [review] [review] > > are relatively inefficient (they are accessed via a string name provided at > > runtime) and also because there's no way to report error information when a > > caller gets or sets a property. > > BTW, one way of dealing with this would be to add a property to the base class > of the DOM objects that would hold the error, so you could do something like > g_object_get (object, "dom-property", &dom, "dom-error", &error, NULL); I guess > you'd define it so that it only holds the first error reported, to match the > semantics of exceptions (meaning that if you try to access several properties > at the same time you'll only get the first error in case there's several..). that would be very neat! except... does it conform to the standard expected method that language-binding auto-generators use to handle execptions? _do_ the auto-generating language-binders (such as python-pygobject) actually _deal_ with exceptions / errors at _all_?? http://www.mail-archive.com/pygtk@daa.com.au/msg12995.html apparently, yes (although that's just the beginning of where it will have been introduced - public api and usage api not yet investigated).

Adam Dingle

Comment 134 2009-02-11 05:07:42 PST

Created attachment 27558 [details] 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. 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 GdomElement WebKitElement WebKitDomElement With either of the last two, we could use vanilla Vala bindings generation rather than the 2-stage process in this Makefile.

Martín Soto

Comment 135 2009-02-11 06:06:17 PST

(In reply to comment #128) >... > My colleague Jim and I are highly interested in seeing DOM bindings added to > WebKit/GTK. Over the last couple of weeks, we've extensively cleaned up and > enhanced the last patch posted here (posted by Martin Soto in comment #96 on > 11/30) in an effort to resolve all outstanding issues. Here is a list of the > major changes we've made, followed by a list of potentially open questions. First of all, I'd like to thank you for taking over. I'm writing my PhD thesis right now and simply haven't found the time to keep this work going. By the way, I must have a few things at home that I didn't manage to publish so far. If I find something interesting, I'll make it available here later today or tomorrow, just in case there are some bits and pieces you can use. Of course, also, it would be nice to get this patch integrated, so that we can easily contribute smaller patches Some additional (random) comments: > - In the last patch, each wrapper GObject pointed to a private structure which > in turn pointed to a native C++ WebKit object. (Comments on this thread show > that there was previously yet one more level of indirection which Martin has > already removed.) These pointers were duplicated at each level of the > inheritance hierarchy. For example, a GdomHTMLButtonElement pointed to a > native HTMLButtonElement, but the parent class GdomHTMLElement and all other > parent classes also contained pointers to the native object. This was > unnecessary and wasteful. I also wanted to remove this level of indirection but didn't know if it was necessary for some reason (ABI stability?). Indeed, virtual machines and interpreters (Python comes to mind) often add a level of indirection of their own, so being as lean as possible on the GObject side is always a plus. > ... > We doubt that will be necessary, but if we do need a private structure > at some point we can simply update the void * to point to it without breaking > binary compatibility with applications that use DOM objects. Sounds great. > GObject wrapper is initialized and call deref() when it's finalized. As some > reviewers pointed out, the existing code called ref() on some smart pointers in > some cases, which was unnecessary; we've eliminated that wherever it happened > in the code. I did this same change in my (unpublished) code and it worked in all of my tests. I went as far as loading arbitrary pages from the Internet and then traversing their DOM using Python, so it seemed to be quite robust. > ... > With our changes, each DOM attribute is exposed both as a property and via > getter/setter methods. When the DOM specifies that getting or setting the > attribute may raise an exception, the corresponding getter/setter method takes > a GError ** for error reporting. We're not particularly attached to using > GObject properties at all, and can remove them if you like; that would > significantly reduce code size (especially in the generated code). It's up to > you. When are properties actually useful? They are unconfortable to use even in Python. For widgets, software such as Glade benefits from them, but they don´t seem to be so useful in the DOM. I wouldn't regret it if they dissapeared. > - The last patch contained some support for reporting DOM events to the GObject > caller. The event interface was different from that specified by the DOM and > the implementation was incomplete (there was no way to unregister an event > listener). In our patch we've removed all the event code, simply because > events raise various design issues and we'd prefer to deal with them in a > subsequent iteration. As various commenters have mentioned, the patch is large > enough as it is and removing the event code seemed like a good way to reduce > its size. This is a good idea for the moment. Events are very important, but we need to get them right. Dedicating an iteration to them seems like the way to go. > [Many clean-up actions described] While we're on it, I noticed that the original patch uses the WebKit namespace in some cases and the WebCore namespace in some other cases. Shouldn't this be unified as well? > - Where possible, we've renamed source and header files to have all-lowercase > names as is conventional in GTK. The autogenerated wrapper files still have > CamelCase names because we use implicit makefile rules to generate these from > .idl files, which also have CamelCase names, and GNU make doesn't allow us to > perform a lowercasing transformation inside the implicit the rule. So the > autogenerated filenames don't quite fit the GTK convention; we don't think this > is a significant problem. Yes, I also ran into this problem. I don't think it is really bad if the generated files use camel case, and it simplifies quite a few things. > == open questions == > > Here are design decisions that potentially remain open along with their current > status. We're happy to change any of these in the code to satisfy the > consensus of the WebKit team. > > 1. How should GObject DOM classes be named? > ... I would be for putting everything under the WebKit GObject "namespace". This is not just some DOM, it's the WebKit DOM, and its classes are in the WebCore C++ namespace together with the rest of WebKit. This way, WebKitElement should do, as it's guaranteed not to conflict with anything wrapped out of the WebCore namespace. That's it. Once again, I'm glad that you guys stepped in. I'm also looking forward to seeing this patch integrated!

Wouter Bolsterlee

Comment 136 2009-02-11 06:12:03 PST

(In reply to comment #135) > When are properties actually useful? They are unconfortable to use even in > Python. For widgets, software such as Glade benefits from them, but they don´t > seem to be so useful in the DOM. I wouldn't regret it if they dissapeared. GObject features notify:: signals, which allows you to attach callback functions that are invoked when a property changes. But perhaps there are other mechanisms for that.

Luke Kenneth Casson Leighton

Comment 137 2009-02-11 06:17:35 PST

(In reply to comment #134) > Created an attachment (id=27558) [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.

Xan Lopez

Comment 138 2009-02-11 06:22:19 PST

Martín Soto

Comment 139 2009-02-11 06:23:34 PST

(In reply to comment #132) > (In reply to comment #128) > > Because we've eliminated the private structure, we can't use a C++ smart > > pointer to point to the native C++ object, and so we call ref() manually when a > > GObject wrapper is initialized and call deref() when it's finalized. > > ahh... the use of ref() and deref() were a key reason why the existing > patch was not accepted. mark cited "use of ref() and deref() typically > indicate broken code and/or broken design". I don't think anyone is being so religious regarding this issue. Thing is, apparently random ref() and deref() thrown around the code don't look like something that is likely to be robust. The strategy taken by Adam, on the other hand, is quite sound, namely, you ref objects once when they are wrapped and deref them once when the wrapper is destroyed. It is as easy as that. Also, the reason you must use explicit ref() and deref() instead of a vanilla RefPtr is that the pointer is inside a C structure. As I said in my previous comment, I tested this strategy at home and it worked really well. It seems to be the most maintainable of the options available and any problems with code readability should be solvable with a few well placed comments.

Martín Soto

Comment 140 2009-02-11 06:30:04 PST

(In reply to comment #136) > GObject features notify:: signals, which allows you to attach callback > functions that are invoked when a property changes. But perhaps there are other > mechanisms for that. Good point. I have one question, though: there will be a lot of situations where properties will change their values "underneath the feet" of the GObject wrappers. Does it mean that all properties we define have to take this case into account and connect events to the DOM in order to listen for changes and fire the corresponding signal? Sounds a bit nasty...

Luke Kenneth Casson Leighton

Comment 141 2009-02-11 06:32:50 PST

> When are properties actually useful? They are unconfortable to use even in > Python. For widgets, software such as Glade benefits from them, but they don�t > seem to be so useful in the DOM. I wouldn't regret it if they dissapeared. i mentioned this earlier, but will repeat it here so that it is clearer, martin. automated property detection in higher-level abstract classes. when providing an abstraction layer on top of python-pygobject bindings, for example, which is what pyjamas-desktop is (it's a port of GWT to python _and_ webkit). all that is needed, to replace javascript code: if (node.offsetWidth > 20) { Window.alert("width > 20"); } is this: if node.offsetWidth > 20: ui.Window.alert("width > 20") that's it. done. finished. underneath, that node.offsetWidth does something like this: def __getattr__(self, property_name): return gdom_node_get_property(property_name) that's all. nothing to it. dead. simple. if you REMOVE property-getting/setting, it gets xxxxing AWFUL: def __getattr__(self, property_name): s = "gdom_node_get_%s" % property_name return eval(s) that's the best "simple" case i can think of, and it's pretty bad. here's the much much worse-case scenario: def __getattr__(self, property_name): t = gdom_node_get_type(self, "type") # argh! can't even get the node type! if t == "element": if property_name == 'width': return gdom_element_get_width() elif property_name == 'height': return gdom_element_get_height() ... ... elif t == '....' ... .... ... ... ... ... this will be about a _thousand_ lines long, and require a _nightmare_ maintenance task as the DOM model is expanded. and that's just "get". what about "set"? yes, you could auto-generate this... but from what? from the original IDL file?? you can't auto-generate it from the .defs file because the information has been lost by that point as to which bits were properties and which bits were truly functions. apologies for spelling it out like this but i hope it's clearer as to why it is so damn important that properties be available as properties. if you're doing a "simple language thing" - great, good luck, go for it, you will have no need for and no purpose for which getter/setter properties are useful. if however you're providing an abstraction layer on top of language bindings on top of the glib/gobject bindings, then having exactly the same access to properties in exactly the same way that javascript has access to properties is utterly essential. l.

Adam Dingle

Comment 142 2009-02-11 06:34:03 PST

(In reply to comment #137) To be clear, in my comment #134 I was just using the Element interface as an arbitrary example. Once we choose a prefix, we'll certainly use it with all DOM interfaces; if we choose WebKit, we'll have WebKitElement, WebKitNode, WebKitHTMLElement and so on.

Luke Kenneth Casson Leighton

Comment 143 2009-02-11 06:39:08 PST

(In reply to comment #138) > Another very important point is that they allow automatic binding generation > through gobject-introspection with the right semantics. *nods vigorously*.

Luke Kenneth Casson Leighton

Comment 144 2009-02-11 07:10:29 PST

(In reply to comment #93) > (In reply to comment #89) > > > Minor issue: getGobjType doesn't follow the naming conventions outlined in the > > > coding style guidelines, due to the same capitalization inconsistency that > > > "Gdom" has in some places in this patch. > > > > i've read the guidelines - i don't understand what i'm missing. > > """ > Use CamelCase. Capitalize the first letter of a class, struct, protocol, or > namespace name. Lower-case the first letter of a variable or function name. > Fully capitalize acronyms. > > Use full words, except in the rare case where an abbreviation would be more > canonical and easier to understand. > """ > I'm not entirely sure which category "gobj" falls in. I suspect it may be an > abbreviation of g_object, in which case GObject would be how it is mapped to > our naming conventions. ohhh, i see. ok, now i understand. it wasn't the camel case that was the issue, it was the abbreviation of the naming. that's the bit i didn't quite follow. apologies. > > btw i started off with GDOM as the prefix and it blew up the pygtk > > auto-generator. i posted a bugreport about that and they said that there was > > absolutely zero intention of fixing pygtk's codegen.py. > > > > so, you _can_ go and replace Gdom with GDOM, and it will screw things up for > > people, further down the line. > > You have used both Gdom and GDOM within the same patch. I'm also not convinced > that an external, third-party tool should be dictating to our naming > conventions either. I'm sure that issue is fixable within that tool or in a > script that wraps the tool. fortunately, the consensus is to use "WebKit" as the prefix, thus side-stepping this issue, thank goodness. as i mentioned before, the python-pygobject auto-generator, h2defs.py, is sufficiently complex that the developers have made it clear that any interfaces that do not conform to the StandardConvention will NOT be supported. leaving a rather awkward pre-processing step, just like the vala bindings. fortunately, using WebKit as the prefix (or WebKitDom) keeps everybody happy, with WebKit being the "preferred" choice. > > > At the very > > > least this shouldn't require duplication of assignments for each possible > > > feature define. The common values could be assigned to a FEATURE_DEFINES > > > variable, with FEATURE_DEFINES_JAVASCRIPT taking its value and adding > > > LANGUAGE_JAVASCRIPT, ENABLE_SVG, etc, and FEATURE_DEFINES_GDOM only adding > > > LANGUAGE_GDOM. Another alternative would be to have FEATURE_DEFINES include > > > all features that are enabled, and FEATURE_DEFINES_GDOM be the result of > > > stripping out any values that mention SVG from the FEATURE_DEFINES variable. > > > > i _may_ be wrong about this: > > > > i wouldn't recommend that _at the moment_, because the person who will be > > expected to create the SVG bindings in the future may choose to implement a > > _small_ subset of the SVG bindings, to begin with. > > > > if the above paragraph translates into "when someone comes to adding SVG > > bindings, then they will either have to implement them all or not at all", then > > it should be clear as to why that is undesirable. > > I'm not sure why you think it translates to that. One way to incrementally > flesh out support is to have the scripts generate code for the entire feature, > but only compile the files that are completely implemented. I think we do that > in some places in the Obj-C DOM in one or two places. oh right. that works. > > > > > rather than JS in the cases that they differ. Many of these instances are due > > > > > to behavioral peculiarities of JS, especially attributes such as > > > > > ConvertNullToNullString and toString functions. > > > > ConvertNullToNullString: agreed. (well, i haven't used it, and > > pyjamas-desktop hasn't blown up. so i don't need it). > > > > toString: disagree. _definitely_ need this one. > > See my previous comment for why this is untrue. i did. but to double-check that i have read it, a cross-reference would be appreciated (we're up to comment #144 so far, so it's difficult to make absolutely sure). when you get to it, could you kindly review the references to de-facto standards implementations of toString in all other competitor products to webkit? for convenience, the researched evidence presented is in comments numbered #121 to #127. comments #121 to #124 are specific research on "toString", indicating that even wine's implementation of MSHTML provides "toString", and it does so by using Gecko's "toString" function. if the wine developers had attempted to use webkit's glib / gobject bindings to do the job, they would FAIL, and would give up, and abandon webkit, because "toString" is "not part of the standard". it's not in the W3C standard, it's part of the de-facto standard, as shown by the evidence presented. > > > There are two issues here: the ref-counting problems tracked in bug 20403, > > > which sound as though they need to be addressed before these bindings will > > > function without crashing, > > > > no. > > > > 1) the crashes caused by #20403 have been demonstrated and proven to have > > absolutely nothing to do with the bindings. at all. nothing. > > > > 2) #20403 has been solved. > > Ok. I was under the impression that the reason your workaround for that issue > was in a previous version of the patch was that it was required in order to > function. Bug 20403 does not appear to have been solved to me: Darin signed > off on the concept of your fix, but some minor revisions were requested and you > have yet to post the updated patch that makes them. i'm happily maintaining a branch of webkit, for a client, and they're happy with it. my apologies for dropping the ball on #20403. > > > and the ref-counting problems within the patch > > > itself. > > > > there have been _no_ ref-counting problems encountered. see earlier comment: > > i would be utterly shocked if there were "negative" refcounting bugs, > > because of the amount of time i've spent running pyjamas-desktop apps. > > > > without crashes of any kind (esp. since i patched in the solution #20403) > > > > i would equally be surprised if there were memory leaks, but you can clearly > > see, if you examine an auto-generated file, that each and every "add ref" > > is matched by a corresponding "dec ref". > > > > so, although it's not _proven_, with test code, this "refcounting problem" > > sounds much like an imaginary invention - a bogeyman in the closet :) > > There are problems. I called out each individually in an earlier comment, so I > am not going to waste my time doing so again. i would ask you kindly to provide a link to which of the 144 comments in this thread that is, but see below. > The fact that you convinced the > incorrect code to work does not make the code correct. The incorrect use of > ref-counting absolutely must be addressed before the change can be landed. ok - fortunately, adam's work involves removal of all c++ objects - entirely. thus making it _essential_ that ref() and deref() are utilised. so, fortunately, this issue can be dropped. three people have now worked on this issue, and three people have all used ref() and deref(). two of them exclusively used ref() and deref() (martin and adam). so, i am quite happy to let them continue discussions with you on resolving and addressing this issue. > > > > 4. Changes to the IDL files. > > > > > > > > Any additional problems I'm missing? Could people please post their > > > > thoughts on the open issues so that we can make some progress? I'll try > > > > to look into issue 4 and see if I can understand what's going on, but > > > > cannot promise anything for the moment. > > > > i wouldn't make the differences without very good reasons and justification. > > > > XMLHTTPRequest open(String) is a good starting point: it's simply too much > > additional work to provide the functionality of TextDocument, when just > > enabling the use of open(String) instead of open(TextDocument) will do just as > > well, if not better. > > > > each of the differences is pretty obvious and straightforward, and i believe > > i've answered and explained them all. > > You have indeed outlined why you made the changes that you did. However, as I > have pointed out several times now, the reasons that you made the changes in > many cases do not align with the WebKit project's vision for native bindings. that vision is a broken vision, one in which webkit fails to be utilised for many projects, and gecko is utilised instead as the only other viable option, thanks to its compliance with de-facto up-to-date standards. i trust that you will review the evidence presented in comments #121-#127 and that the webkit vision will be updated accordingly, so that the webkit vision for native bindings includes conformance to de-facto standards as part of the vision. strict adherence to W3C standards as part of the webkit project vision will result in the need to rip out non-W3C-compliant features such as "offsetWidth" and "offsetHeight". i trust that the webkit team are reasonable people whom, when presented with good evidence, will be happy to work with people who would like to see webkit's vision and webkit's usefulness expanded.

Luke Kenneth Casson Leighton

Comment 145 2009-02-11 07:14:18 PST

adam, when removing all of the "differences" between javascript and gobject bindings, did you also remove the XMLHttpRequest open() function as a string rather than as a TextDocument? if you did so, then there is no way to utilise XMLHTTPRequest and therefore no way to do AJAX using the glib / gobject bindings. why? because you can't _get_ at the TextDocument interface, because it's not properly exposed via the glib / gobject bindings. i spent several days trying to get that one right, and in the end i gave up and re-activated the XMLHttpRequest.open(string) function and disabled the XMLHttpRequest.open(TextDocument*) function.

Luke Kenneth Casson Leighton

Comment 146 2009-02-11 07:15:21 PST

(In reply to comment #142) > (In reply to comment #137) > > To be clear, in my comment #134 I was just using the Element interface as an > arbitrary example. Once we choose a prefix, we'll certainly use it with all > DOM interfaces; if we choose WebKit, we'll have WebKitElement, WebKitNode, > WebKitHTMLElement and so on. :) ok - just checking :)

Adam Dingle

Comment 147 2009-02-11 08:47:45 PST

(In reply to comment #145) > adam, > > when removing all of the "differences" between javascript and gobject > bindings, did you also remove the XMLHttpRequest open() function as a > string rather than as a TextDocument? Actually you mean the XMLHttpRequest send() function. A bit of background: the W3C XMLHttpRequest draft specification (http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) includes several overloaded versions of send(): void send(); void send(in DOMString data); void send(in Document data); In WebKit's XMLHttpRequest.idl, the first two of these are commented out, although the underlying WebKit XMLHttpRequest object actually supports all three of these. I believe that the WebKit team has commented out overloaded functions wherever they occur in IDL files because certain language bindings can't handle overloads. C, in particular, doesn't allow overloaded functions, so if all three send() methods were exposed today, the GObject bindings would fail to compile. So only send(in Document data) is available at the moment. You might be able to use that to do AJAX now: from any Document object you can get a DOMImplementation, which you could possibly use to construct new Document objects containing arbitrary text. I haven't tried that myself, however. The current patch does not include any changes to XMLHttpRequest.idl. If you'd like that IDL file to expose a different overload of send(), I'd suggest you take that up in an independent bug report; that change would affect other language bindings and is essentially independent of the GObject changes here. The best solution here would be to uncomment overloaded functions in the IDL and make the language bindings generators smart enough to map them into non-overloaded functions using alternate names when necessary. We could either (a) have the bindings generators derive alternate names automatically, e.g. send_DOMString() and send_Document(), and/or (b) add IDL attributes that suggest alternate names. I'd love to see that happen, but I think that's beyond the scope of this first GObject/DOM iteration.

Mark Rowe (bdash)

Comment 148 2009-02-11 09:02:47 PST

(In reply to comment #136) > (In reply to comment #135) > > When are properties actually useful? They are unconfortable to use even in > > Python. For widgets, software such as Glade benefits from them, but they don´t > > seem to be so useful in the DOM. I wouldn't regret it if they dissapeared. > > GObject features notify:: signals, which allows you to attach callback > functions that are invoked when a property changes. But perhaps there are other > mechanisms for that. This would require that the WebCore DOM notify the GObject bindings when a DOM property changes. It's unlikely that we'd be able to do this without a substantial performance impact on DOM operations, even when no-one is listening for notifications. The DOM itself supports mutation events that are fired when attributes are added, removed or modified, but as they have a measurable performance impact even if unused we have chosen not to support them at this time (they're #if'd out in the code).

Mark Rowe (bdash)

Comment 149 2009-02-11 09:07:02 PST

(In reply to comment #147) > The best solution here would be to uncomment overloaded functions in the IDL > and make the language bindings generators smart enough to map them into > non-overloaded functions using alternate names when necessary. We could either > (a) have the bindings generators derive alternate names automatically, e.g. > send_DOMString() and send_Document(), and/or (b) add IDL attributes that > suggest alternate names. I'd love to see that happen, but I think that's > beyond the scope of this first GObject/DOM iteration. The solution taken by the JS bindings is to implement a custom (eg, hand-written) binding for XMLHttpRequest::send, which is indicated by the [Custom] annotation in the IDL. The custom binding then detects the type of the argument and acts accordingly. It may be possible for the GObject bindings to do something similar. I agree that this should be left to a follow-up change after the core functionality goes in.

Xan Lopez

Comment 150 2009-02-11 09:18:24 PST

(In reply to comment #148) > (In reply to comment #136) > > GObject features notify:: signals, which allows you to attach callback > > functions that are invoked when a property changes. But perhaps there are other > > mechanisms for that. > > This would require that the WebCore DOM notify the GObject bindings when a DOM > property changes. It's unlikely that we'd be able to do this without a > substantial performance impact on DOM operations, even when no-one is listening > for notifications. The DOM itself supports mutation events that are fired when > attributes are added, removed or modified, but as they have a measurable > performance impact even if unused we have chosen not to support them at this > time (they're #if'd out in the code). > That's a good point. We still could use gobject properties and get the other mentioned benefits though, we only need to NOT notify changes and document why we don't do it. I think that's easy doable, we just need to not use g_object_set (or variants) internally and make our setters not call g_object_notify (which I take it is what's going on right now).

Adam Dingle

Comment 151 2009-02-11 09:36:32 PST

> > When are properties actually useful? > > Another very important point is that they allow automatic binding generation > through gobject-introspection with the right semantics. gobject-introspection is aware of both properties and methods. The Vala bindings generator, for example, uses (a version of) gobject-introspection to find out about GObject classes. Each GObject property becomes a Vala property, and each GObject method becomes a Vala method. With the current patch DOM objects have both properties and getters/setters, and all of these end up reflected into the Vala world. So in Vala you could write either node.parent_node or node.get_parent_node(), for example. It's not clear to me what you mean by "the right semantics" here. Are you asserting that DOM attributes should be reflected into higher-level languages as properties in those languages, and that gobject-introspection can enable that only if they are available as GObject properties? Is there some specific application or use case that will suffer if attributes are available only through getters/setters?

Jim Nelson

Comment 152 2009-02-11 09:55:21 PST

(In reply to comment #131) > BTW, one way of dealing with this would be to add a property to the base class > of the DOM objects that would hold the error, so you could do something like > g_object_get (object, "dom-property", &dom, "dom-error", &error, NULL); I guess > you'd define it so that it only holds the first error reported, to match the > semantics of exceptions (meaning that if you try to access several properties > at the same time you'll only get the first error in case there's several..). Of > course setter/getter functions are easier because you can only access one > property at a time :) Doesn't it make more sense to simply have a global (or per-thread) "last DOM exception" variable, a la errno? (It could be exposed via a function call, to be clean about it.) Plus, it sounds like the caller would have to invoke a "clear last error" object method before accessing a sequence of properties, otherwise the first error will persist when no exception has occurred in the latest batch of operations. Although I'm not thrilled with global values for error-reporting, if the caller is interested in capturing exceptions, then they should be using getter/setters, where exceptions are properly reported.

Xan Lopez

Comment 153 2009-02-11 10:00:51 PST

(In reply to comment #151) > > > When are properties actually useful? > > > > Another very important point is that they allow automatic binding generation > > through gobject-introspection with the right semantics. > > gobject-introspection is aware of both properties and methods. The Vala > bindings generator, for example, uses (a version of) gobject-introspection to > find out about GObject classes. Each GObject property becomes a Vala property, > and each GObject method becomes a Vala method. With the current patch DOM > objects have both properties and getters/setters, and all of these end up > reflected into the Vala world. So in Vala you could write either > node.parent_node or node.get_parent_node(), for example. Sure. Many bindings do this, the old ones not using gobject-introspection too. For instance foo.get_bar() vs foo.props.bar in PyGObject, IIRC. > > It's not clear to me what you mean by "the right semantics" here. Are you > asserting that DOM attributes should be reflected into higher-level languages > as properties in those languages, and that gobject-introspection can enable > that only if they are available as GObject properties? Yes, I meant exactly that. You can construct high-level properties from the getters/setters, but then you'd have to do this manually (like in the example Luke has written). Of course I'm assuming you actually want to use DOM properties as properties in your language, which is the next point. > Is there some specific application or use case that will suffer if attributes > are available only through getters/setters? Well, one big point IMHO is the discoverability of the API. At least in my case I'd expect to have DOM properties accessible as actual properties of an object, and not only as getters/setters. I expect I won't be alone in this, so forcing bindings authors to do this manually seems like a big point for me. Another property of properties (pun not intended ;)) that I've used heavily in languages like JavaScript or Lisp is the hability to programatically generate the names of the properties you want to read or set. Depending on the language this can be done more or less easily with functions too, but in general it's considerably more cumbersome. And of course there's notifies, but Brian has told us that enabling that would probably be a big performance issue, so I guess we can leave that out (at least for now).

Xan Lopez

Comment 154 2009-02-13 01:10:37 PST

The patch breaks srcdir != builddir builds btw. It seems to delete a bunch of -I$(top_builddir)... for no apparent reason and replaces other $(builddir) with $(srcdir) variants. I just fixed it by reverting those, but for some reason also had to go to WebKitTools/GNUmakefile.am and add -I$(top_builddir)... flags to the tools flags.

Xan Lopez

Comment 155 2009-02-13 01:12:58 PST

Created attachment 27645 [details] GdomHTMLTableRowElement.cpp

Xan Lopez

Comment 156 2009-02-13 01:13:43 PST

Created attachment 27646 [details] GdomHTMLTableRowElement.h

Xan Lopez

Comment 157 2009-02-13 01:14:56 PST

Created attachment 27647 [details] GdomAttr.cpp

Xan Lopez

Comment 158 2009-02-13 01:15:29 PST

Created attachment 27648 [details] GdomAttr.h

Xan Lopez

Comment 159 2009-02-13 01:16:09 PST

Added a few of the autogenerated files per Mark's request.

Xan Lopez

Comment 160 2009-02-13 01:33:52 PST

Created attachment 27649 [details] GdomAttrPrivate.h

Xan Lopez

Comment 161 2009-02-13 01:34:29 PST

Created attachment 27650 [details] GdomHTMLTableRowElementPrivate.h

Mark Rowe (bdash)

Comment 162 2009-02-13 01:46:15 PST

Thanks Xan, I'll have a look at these shortly. Do we have any resolution to the API naming issue?

Xan Lopez

Comment 163 2009-02-13 03:10:46 PST

I think the consensus is to go with something starting with WebKit for consistency sake, but I don't think a definitive one has been picked. I'm fine with either WebKit, WebKitDOM, WebKitDom, or whatever, but I think somenone commented using WebKitDom/DOM would have the advantage of grouping all symbols in references.

Christian Dywan

Comment 164 2009-02-13 05:56:21 PST

(In reply to comment #163) > I think the consensus is to go with something starting with WebKit for > consistency sake, but I don't think a definitive one has been picked. I'm fine > with either WebKit, WebKitDOM, WebKitDom, or whatever, but I think somenone > commented using WebKitDom/DOM would have the advantage of grouping all symbols > in references. I would think WebKitFoo is better than something with G, otherwise it looks like a part of Glib. Using WebKitDom is probably the best idea not only for sorting in a reference, but because there is not only WebKitFooElement but also generic symbols such as WebKitAttr. Alternatively we could explicitly make WebKitAttr => WebKitDomAttr and still go with WebKitFooElement.

Christian Dywan

Comment 165 2009-02-13 06:00:57 PST

(In reply to comment #155) > Created an attachment (id=27645) [review] > GdomHTMLTableRowElement.cpp > GdomHTMLTableRowElement *thiz This should say "GdomHTMLTableRowElement *element", that's the usual convention in Gtk. We might also add a "g_return_val_if_fail (!error || !*error, 0);" here. > if(ec) What happens if "error" is not set? We probably need "if(ec && error)" here?

Christian Dywan

Comment 166 2009-02-13 06:07:58 PST

(In reply to comment #165) > (In reply to comment #155) > > Created an attachment (id=27645) [review] [review] > > GdomHTMLTableRowElement.cpp > > > GdomHTMLTableRowElement *thiz And an even more obvious one, we need "g_return_val_if_fail (GDOM_IS_HTML_TABLE_ROW_ELEMENT (element), 0);" here :)

Christian Dywan

Comment 167 2009-02-13 06:16:51 PST

(In reply to comment #166) > (In reply to comment #165) > > (In reply to comment #155) > > > Created an attachment (id=27645) [review] [review] [review] > > > GdomHTMLTableRowElement.cpp > > > > > GdomHTMLTableRowElement *thiz > gdom_html_table_row_element_set_ch_off (GdomHTMLTableRowElement *thiz, gchar * value) This fails if 'value' is NULL. I would think it would be easy on the API side if we allowed NULL and the _get_ counterpart also returns NULL if it's empty. Otherwise you have to do if(value && *value) in all code using that API, if you want to know if the value is actually empty.

Christian Dywan

Comment 168 2009-02-13 06:23:55 PST

(In reply to comment #167) > GdomHTMLTableRowElement * > wrapHTMLTableRowElement(WebCore::HTMLTableRowElement *coreObject) > { > g_return_val_if_fail(coreObject != NULL, NULL); > > GdomHTMLTableRowElement *wrapper = > GDOM_HTML_TABLE_ROW_ELEMENT(g_object_new(GDOM_TYPE_HTML_TABLE_ROW_ELEMENT, NULL)); > g_return_val_if_fail(wrapper != NULL, NULL); That's not quite right. For one, _return_if_fail is meant to be used for public API, and not for implementation details. The first line should rather be ASSERT(coreObject). Further more g_object_new cannot fail, it's no use to check the return value for NULL. If it ever is unable to allocate enough memory it will abort.

Christian Dywan

Comment 169 2009-02-13 06:29:26 PST

(In reply to comment #168) > (In reply to comment #167) > g_object_class_install_property (g_klass, PROP_BG_COLOR, > g_param_spec_string ("bg_color", /* name */ > "html_table_row_element_bg_color", /* short description */ > "read-write gchar * HTMLTableRowElement.bg_color", /* longer - > could do with some extra doc stuff here */ > "", /* default */ > (GParamFlags)G_PARAM_READWRITE)); Identifiers should use hyphens (-) and the nick (the second string) should be Upper Cased. Like this g_param_spec_string ("bg-color", /* name */ "Html Table Row Element Bg Color", /* short description */

Christian Dywan

Comment 170 2009-02-13 06:32:38 PST

(In reply to comment #156) > Created an attachment (id=27646) [review] > GdomHTMLTableRowElement.h > struct _GdomHTMLTableRowElement { > GdomHTMLElement parent_instance; > }; > > struct _GdomHTMLTableRowElementClass { > GObjectClass parent_class; > }; The second struct should contain "GdomHTMLTableRowElementClass parent_class;"

Adam Dingle

Comment 171 2009-02-13 07:58:56 PST

Thanks for the detailed feedback on the generated code. We will address all issues you've pointed out in the next patch iteration. We'll also ensure that srcdir != builddir builds work; unfortunately we didn't get around to testing these last time around. Regarding the naming prefix, it seems the clear consensus is to use something starting with WebKit. I don't think we should use WebKitDOM since it's been pointed out that the all-caps acronym will confuse the Python bindings generator. There are really three possibilities: 1. WebKit: WebKitDOMObject, WebKitDOMWindow, WebKitElement, WebKitHTMLElement, and so on. 2. WebKitDom, strictly: WebKitDomDOMObject, WebKitDomDOMWindow, WebKitDomElement, WebKitDomHTMLElement, and so on. 3. WebKitDom, but removing the "DOM" where it's redundant: WebKitDomObject, WebKitDomWindow, WebKitDomElement, WebKitDomHTMLElement, etc. (There are a total of 7 interfaces where the name DOM would get spliced out.) It's been pointed out by me and others that an advantage of WebKitDom is that all DOM classes would get grouped together. On the other hand, there are presently only 10 non-DOM WebKit classes, and all but one of these begin with WebKitWeb: we have WebKitWebFrame, WebKitWebView and so on. The sole exception is WebKitNetworkRequest. So even if we choose (1) above, all DOM classes will still essentially appear together: they will consist of all classes in a long list save the few that begin with WebKitWeb and one other exception. Regarding implementation, (1) or (2) are easy. (3) is slightly tricky, but probably doable. Due to the limitations of GNU Make's implicit rules, we'd probably have to let the Makefile generate source/object files with full names such as WebKitDomDOMObject.cpp, then have additional rules that copy or rename these files to have the names we want such as WebKitDomObject.cpp. The Perl script would of course also have to know how to splice these names. But I think we can take this on if the consensus is that it's what we want.

Adam Dingle

Comment 172 2009-02-13 08:20:09 PST

(In reply to comment #164) > Alternatively we could explicitly make > WebKitAttr => WebKitDomAttr and still go with WebKitFooElement. To be complete, this is naming possibility (4): we could use the Dom prefix only for certain generic-looking names such as Attr. To do this, we'd have to agree on exactly when this happens. For example, is it WebKitDomNode, or WebKitNode? WebKitDomText, or WebKitText? These decisions seem pretty arbitrary, so I might lean away from this possibility.

Christian Dywan

Comment 173 2009-02-13 09:04:51 PST

(In reply to comment #172) > (In reply to comment #164) > > Alternatively we could explicitly make > > WebKitAttr => WebKitDomAttr and still go with WebKitFooElement. > > To be complete, this is naming possibility (4): we could use the Dom prefix > only for certain generic-looking names such as Attr. To do this, we'd have to > agree on exactly when this happens. For example, is it WebKitDomNode, or > WebKitNode? WebKitDomText, or WebKitText? These decisions seem pretty > arbitrary, so I might lean away from this possibility. In fact WebKitText is technically out of the question, because it would conflict with for instance GtkText in object oriented programming languages. To make my suggestion less arbitrary, how does it sound to leave out the *Dom* for all *Element classes? Considering that this comes down to *HTML*Element anyway.

Gustavo Noronha (kov)

Comment 174 2009-02-13 09:12:26 PST

(In reply to comment #173) > In fact WebKitText is technically out of the question, because it would > conflict with for instance GtkText in object oriented programming languages. > > To make my suggestion less arbitrary, how does it sound to leave out the *Dom* > for all *Element classes? Considering that this comes down to *HTML*Element > anyway. I believe we should add Dom to all classes. Those prefixes are our way of expressing namespaces, and we should be consistent with that, unless I am missing something, and some classes are not specific to the DOM bindings.

Adam Dingle

Comment 175 2009-02-15 11:20:43 PST

(In reply to comment #165) > We might also add a "g_return_val_if_fail (!error || !*error, 0);" here. > > > if(ec) > > What happens if "error" is not set? We probably need "if(ec && error)" here? Actually the existing code is intended to allow the caller to pass NULL for error to ignore any error condition, so we don't want to g_return_val_if_fail (!error). In the generated code, the call to g_set_error_literal() is benign if error == NULL, in which case that function does nothing by design (as described in its documentation).

Adam Dingle

Comment 176 2009-02-15 11:25:09 PST

(In reply to comment #167) I'm currently working on a new patch, and hope to post it here within the next few days. Christian, fortunately most of the points you raised have been straightforward to deal with. One question about this: > > gdom_html_table_row_element_set_ch_off (GdomHTMLTableRowElement *thiz, gchar * value) > > This fails if 'value' is NULL. I would think it would be easy on the API side > if we allowed NULL and the _get_ counterpart also returns NULL if it's empty. > Otherwise you have to do if(value && *value) in all code using that API, if you > want to know if the value is actually empty. The easiest way to fix this is to simply stop checking all string arguments for NULL; instead, we can pass them to WebKit and let it complain if it's not happy with a NULL argument. Can you confirm that this seems like a reasonable idea?

Christian Dywan

Comment 177 2009-02-15 16:13:38 PST

(In reply to comment #175) > (In reply to comment #165) > > > We might also add a "g_return_val_if_fail (!error || !*error, 0);" here. > > > > > if(ec) > > > > What happens if "error" is not set? We probably need "if(ec && error)" here? > > Actually the existing code is intended to allow the caller to pass NULL for > error to ignore any error condition, so we don't want to g_return_val_if_fail > (!error). In the generated code, the call to g_set_error_literal() is benign > if error == NULL, in which case that function does nothing by design (as > described in its documentation). You are misreading the code here. "!error || !*error" written out means "return with a critical warning if error is non-NULL and *error is also non-NULL, pass if error is NULL or if *error is NULL". In other words, pass NULL if you are not interested in errors, but *if* you pass an error, it has to be initialized as an empty error. > > > gdom_html_table_row_element_set_ch_off (GdomHTMLTableRowElement *thiz, gchar * value) > The easiest way to fix this is to simply stop checking all string arguments for > NULL; instead, we can pass them to WebKit and let it complain if it's not happy > with a NULL argument. Can you confirm that this seems like a reasonable idea? Letting *WebCore* complain from my experience usually means a segmentation fault, I certainly don't want that. What I'm suggesting is to define NULL as empty, and return NULL if a value is unset.

Adam Dingle

Comment 178 2009-02-16 09:09:54 PST

(In reply to comment #177) > > You are misreading the code here. "!error || !*error" written out means... You're right: I was misreading this. Thanks for the explanation. I now agree that "g_return_val_if_fail (!error || !*error, 0)" makes sense. I still believe that we don't actually need "if(ec && error)", because g_set_error_literal() does nothing when passed NULL. It wouldn't hurt to have "if(ec && error)" and it might make the code slightly clearer. On the other hand, this is generated code which will get duplicated in a zillion places, so I still might lean toward omitting the "&& error", though I don't care strongly about this. > > The easiest way to fix this is to simply stop checking all string arguments for > > NULL; instead, we can pass them to WebKit and let it complain if it's not happy > > with a NULL argument. Can you confirm that this seems like a reasonable idea? > > Letting *WebCore* complain from my experience usually means a segmentation > fault, I certainly don't want that. What I'm suggesting is to define NULL as > empty, and return NULL if a value is unset. I believe that if we were to simply stop checking string attributes for NULL, you'd have pretty much the behavior you are looking for. When setting an attribute of type DOMString, a setter function such as HTMLTableRowElement::setChOff calls Element::setAttribute(const AtomicString& name, const AtomicString& value, ExceptionCode& ec) to do its work. The source code for that function reveals that if value is NULL, the attribute is removed; no segmentation fault should result. Similarly, a getter function such as HTMLTableRowElement::chOff calls Element::getAttribute(const QualifiedName& name), which returns the null string if the attribute is not present. The returned null string is passed to our converter function gdom_gstring_convert to convert it to a (gchar *); this function will pass it to g_strdup(), which safely maps NULL to NULL, which will be returned. As far as I can tell, in WebKit a string attribute might be either absent, or the empty string, or a non-empty string. We could additionally consider mapping a returned empty string to NULL in an attribute getter; I'm not sure, but I think you may be saying you want this. I think I'm uninclined to do this, since there may be attributes where there is a semantic difference between NULL and the empty string, and if those should be unified I think it should probably not happen in this layer. A more general question is whether we should stop checking all string arguments for NULL, not merely arguments to attribute setters. From a quick glance through the DOM I can't seem to find any methods where passing a NULL string would make sense. So I now propose that we stop checking for NULL in string attribute setters only, and leave the other NULL checks in place.

Adam Dingle

Comment 179 2009-02-18 14:28:30 PST

Created attachment 27762 [details] new patch, updated to revision 41018 Here's a new patch. It includes the following changes: - We've updated the patch to work with a current WebKit build (r41018, the latest nightly build). - Builds with srcdir != builddir now work. - We've continued to refactor and clean up the code, especially the Perl script that generates the GObject bindings. As a result the patch has continued to shrink: it now weighs in at 3239 lines, a reduction of over 250 lines from the previous iteration. - All of Christian's points raised in comments #165-#170 have been addressed. Regarding NULL checking as he discussed in #167, we now perform no NULL checks for attribute setter functions. This is what I suggested in #178, but we skip the NULL checks for all types, not just strings. This makes sense for two reasons: first, NULL may legitimately be used to remove an attribute, and second, the existing code doesn't check for NULL when an attribute is set via setting a GObject property, and so it makes sense to make setter functions behave the same way. In this patch DOM classes still use the Gdom prefix. I'd like to change that soon. In comment #171 I suggested three naming possibilities, but I still don't feel like I've heard a clear consensus as to which is best. At this point I don't like #2 because it would lead to odd names in higher-level language bindings: in particular, in Vala it would lead to classes named DomDOMObject and DomDOMWindow, for example. So I vote for either #1 ("WebKit") or #3 ("WebKitDom", splicing out duplicate instances of the word Dom). Here's what class names in Vala would look like with each possibility: #1: DOMObject, DOMWindow, Element, HTMLElement #3: DomObject, DomWindow, DomElement, DomHTMLELement Feedback is welcome!

Jim Nelson

Comment 180 2009-03-03 18:15:54 PST

Regarding the name prefix, I've looked over the suggestions that have come up over the past few weeks as well as examined the multitude of files being generated by the automatic bindings, and conclude we should use the plain "WebKit" prefix (that is, Adam's option 1 in comment #171). First, not all the generated classes are part of the DOM specification. The SQL classes, Plugin and PluginArray, and WebKitAnimationEvent all appear to be outside the DOM spec, and there are certainly more. The XMLHttpRequest and XPath IDLs are W3C specifications, but also appear outside the DOM. Thus, a class called WebKitDomPlugin is technically wrong. Christian brought up in comment #173 that WebKitText would clash with GtkText in object oriented languages. However, a class called Text is common beyond Gtk. Name collisions are not a unique problem. I know it's inconvenient to have to fully qualify the name in source, but it's not unprecedented. Considering the wide gamut of the generated classes and the various requirements we're placed under here -- that the classes may be invoked in C, Python, Vala, and beyond, and that they all do not live inside the DOM spec -- I think the plain "WebKit" prefix is the way to go. If maintaining namespace is necessary, as Gustavo mentions in comment #174, we're going to need multiple namespaces for the various types of classes (DOM, WebKit-specific, XML-HTTP, etc.). In some ways, that's already been done for us. I count 7 namespaces already declared by virtue of consistent naming: CSS*, DOM*, HTML*, SQL*, SVG*, WebKit* (i.e. WebKitAnimationEvent.idl), XMLHttp*, and XPath*. The generic classes outside those namespaces (i.e. Attr, WheelEvent, Screen) would have to be categorized further to their appropriate namespace, since they're not all DOM (or of any other common grouping). But since we're talking about over 300 classes (in the full JS bindings), this seems extraordinarily complex and unnecessary. If someone would care to provide such a taxonomy in a text file, I'd be happy to consider it. For now, however, I vote we move forward with the unadorned "WebKit" prefix. -- Jim

Xan Lopez

Comment 181 2009-03-05 04:18:51 PST

(In reply to comment #179) > Created an attachment (id=27762) [review] Just a few more comments: #include "ScriptController.h" +#include "TextDocument.h" #include "SubstituteData.h" Would be good to keep this in alphabetical order. /** + * webkit_web_frame_get_xml_http_request: + * @frame: a #WebKitWebFrame + * + * returns a Gdom wrapper around an XMLHttpRequest + * + * Return value: a GdomXMLHttpRequest + */ You need to add "Since: 1.1.2" to all new public functions doc string. (If we don't make it for 1.1.2, we'll change it to 1.1.3, and so on). + PassRefPtr<DOMWindow> win = coreFrame->domWindow(); + return GDOM_DOM_WINDOW(WebKit::toGDOM(win.get())); What's the point of using a PassRefPtr here? I think it adds unnecessary refcount churning, and that this is enough: return GDOM_DOM_WINDOW(WebKit::toGDOM(coreFrame->domWindow())); +WEBKIT_API GdomXMLHttpRequest * +webkit_web_frame_get_xml_http_request (WebKitWebFrame *frame); + +WEBKIT_API GdomDOMWindow * +webkit_web_frame_get_dom_window (WebKitWebFrame *frame); We try to keep this aligned in headers. +2009-02-18 Luke Kenneth Casson Leighton <lkcl@lkcl.net> + + Implemented GTK DOM binding. + + * gtk/webkit/webkitwebframe.cpp: + * gtk/webkit/webkitwebframe.h: Here add the bug URL and title too (and same in all changelogs). webcore_cppflags += \ + -I$(srcdir)/WebKit/gtk \ + -I$(srcdir)/WebKit/gtk/WebCoreSupport \ + -I$(srcdir)/WebKit/gtk/webkit \ -I$(srcdir)/WebCore \ + -I$(srcdir)/WebCore/bindings/gdom \ -I$(srcdir)/WebCore/bindings/js \ We could fix indentation here while we are at it :) +#include "gdom/GdomHTMLElementPrivate.h" +#include "gdom/GdomHTMLAnchorElementPrivate.h" Alphabetical order again. +gpointer GDOMObjectCache::getDOMObject(void* objectHandle) +{ + gpointer ret = domObjects().get(objectHandle); + return ret; +} No need for variable. Also, I agree the prefix WebKit seems to make the most sense here, so +1 from me on that.

Jim Nelson

Comment 182 2009-03-06 17:49:43 PST

Created attachment 28381 [details] GTK DOM bindings This patch incorporates all previous patches, renames the classes to the "WebKit" prefix, and addresses Xan's requests in comment #181. The bindings generator has been tightened up not to produce unnecessary property getters and setters as well. This was generated against revision #41443. We believe this is a solid candidate for inclusion and a good step toward rich GTK support. Please let us know what you think! Thanks, -- Jim

Jan Alonzo

Comment 183 2009-03-07 06:52:04 PST

Comment on attachment 28381 [details] GTK DOM bindings Hi Jim > Index: GNUmakefile.am > =================================================================== > --- GNUmakefile.am (revision 41443) > +++ GNUmakefile.am (working copy) > @@ -31,6 +31,7 @@ > > # Directory for autogenerated sources > GENSOURCES := $(top_builddir)/DerivedSources > +GENSOURCESGOBJECT := $(top_builddir)/DerivedSources/webkit > GENPROGRAMS := $(top_builddir)/Programs Can we rename the build-related GOBJECT wording to GDOM i.e. GENSOURCESGOBJECT -> GENSOURCESGDOM ? > # Script for creating hash tables > @@ -103,7 +104,8 @@ > -I$(srcdir)/JavaScriptCore/ForwardingHeaders \ > -I$(srcdir)/JavaScriptCore/parser \ > -I$(srcdir)/JavaScriptCore/wtf \ > - -I$(top_builddir)/DerivedSources > + -I$(top_builddir)/DerivedSources \ > + -I$(srcdir)/WebCore/bindings/webkit No need to include .../bindings/webkit to the JSC build. > +webcoregtk_cppflags += \ > + -I$(top_builddir)/DerivedSources/webkit \ > + -I$(srcdir)/WebCore/bindings \ > + -I$(srcdir)/WebCore/bindings/gobject > + Please add the lines above to webcoregtk_cppflags in WebCore/GNUmakefile.am > nodist_EXTRA_libWebCore_la_SOURCES = \ > $(webcore_built_nosources) > > @@ -193,6 +200,7 @@ > libWebCore_la_LIBADD = \ > libJavaScriptCore.la \ > libWebCoreJS.la \ > + libgobject.la \ Let's name the libtool archive to libWebCoreGDOM.la > +libgobject_ladir = $(prefix)/include/webkit-1.0/webkit > +libgobject_la_HEADERS = \ > + $(libgobject_h_api) > + Ditto and libwebcoregdom_h_api.Also declare libwebcoregdom_h_api before libgobject_ladir above. > # WebKit > webkitgtk_h_api := > webkitgtk_sources := > @@ -360,12 +372,14 @@ > -I$(srcdir)/WebKit/gtk \ > -I$(srcdir)/WebKit/gtk/WebCoreSupport \ > -I$(srcdir)/WebKit/gtk/webkit \ > - -I$(top_builddir)/WebKit/gtk/webkit > + -I$(top_builddir)/WebKit/gtk/webkit \ > + -I$(top_builddir)/DerivedSources Add DerivedSources/webkit here too. > # END WEBKIT GTK+ > # > # Files that will be distributed > @@ -466,6 +526,7 @@ > # Build unit test > noinst_PROGRAMS += Programs/UnitTests > Programs_UnitTests_CPPFLAGS = \ > + -I$(srcdir)/WebCore/bindings \ I don't think we need to include it. > @@ -494,7 +555,8 @@ > $(webcore_built_sources) \ > $(webcore_built_nosources) \ > $(webkitgtk_built_sources) \ > - $(webkitgtk_built_nosources) > + $(webkitgtk_built_nosources) \ > + $(gobject_built_nosources) gdom_built_sources. > Index: WebCore/GNUmakefile.am > =================================================================== > --- WebCore/GNUmakefile.am (revision 41443) > +++ WebCore/GNUmakefile.am (working copy) > @@ -1,7 +1,7 @@ > > webcore_cppflags += \ > + -I$(srcdir)/WebKit/gtk \ > + -I$(srcdir)/WebKit/gtk/WebCoreSupport \ > + -I$(srcdir)/WebKit/gtk/webkit \ Do we need to include WebKit here? > -I$(srcdir)/WebCore \ > + -I$(srcdir)/WebCore/bindings/gobject \ > -I$(srcdir)/WebCore/bindings/js \ > -I$(srcdir)/WebCore/bridge \ > -I$(srcdir)/WebCore/bridge/c \ > @@ -57,6 +61,7 @@ > DerivedSources/DocTypeStrings.cpp \ > DerivedSources/tokenizer.cpp \ > DerivedSources/ColorData.c \ > + DerivedSources/webkit/webkitdomdummy.c \ This should go to gdom_built_nosources and please add it to BUILT_SOURCES too > @@ -240,6 +245,14 @@ > WebCore/xml/XMLSerializer.idl \ > WebCore/xml/XSLTProcessor.idl > > +webcoregtk_sources += \ > + WebCore/bindings/gobject/webkitbinding.cpp \ > + WebCore/bindings/gobject/webkitbinding.h \ > + WebCore/bindings/gobject/WebKitDOMObject.cpp \ > + WebCore/bindings/gobject/WebKitDOMObject.h \ > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp \ > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.h Please add the sources above to webcoregtk_sources in line ~1730 Kindly rename GOBJECT to GDOM accordingly from here on (i.e. GOBJECT_AUTO_..., GOBJECT_FIXED_..., GOBJECT_CLASSES, etc...) > +# Bindings autogenerated in GObject, but not in JS. > +IDL_BINDINGS_GOBJECT_EXTRA := \ > + WebCore/html/CanvasPixelArray.idl > + > +# Bindings autogenerated in JS, but not in GObject. > +IDL_BINDINGS_GOBJECT_MINUS := > + > +# All IDL files used for autogeneration in GObject. We filter out SVG and events for now. Please add a FIXME re SVG and events ^^^ - as we might need to add it later > +gobject_built_nosources := $(GOBJECT_HEADERS_BUILT) $(GOBJECT_SOURCES_BUILT) This should be _built_sources not _built_nosources. > Index: WebCore/bindings/gobject/WebKitDOMObject.cpp > =================================================================== > --- WebCore/bindings/gobject/WebKitDOMObject.cpp (revision 0) > +++ WebCore/bindings/gobject/WebKitDOMObject.cpp (revision 0) > @@ -0,0 +1,28 @@ > +/* > + * Copyright (C) 2008 Luke Kenneth Casson Leighton <lkcl@lkcl.net> > + * Copyright (C) 2008 Martin Soto <soto@freedesktop.org> > + * Copyright (C) 2008 Alp Toker <alp@atoker.com> > + * Copyright (C) 2008 Apple Inc. All Rights Reserved. > + */ > + Please include the license header here. > Index: WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp > =================================================================== > --- WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp (revision 0) > +++ WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp (revision 0) > +#include "webkithtmlelementwrapperfactory.h" Why are the following lines prefixed with "webkit/"? We're already including DerivedSources/webkit anyway. > +#include "webkit/webkitdom.h" > + > +#include "webkit/WebKitHTMLAnchorElementPrivate.h" > +#include "webkit/WebKitHTMLAppletElementPrivate.h" > +#include "webkit/WebKitHTMLAreaElementPrivate.h" > +#include "webkit/WebKitHTMLBaseElementPrivate.h" > +#include "webkit/WebKitHTMLBaseFontElementPrivate.h" > +#include "webkit/WebKitHTMLBlockquoteElementPrivate.h" > +#include "webkit/WebKitHTMLBodyElementPrivate.h" [....] > Index: WebKitTools/GNUmakefile.am > =================================================================== > --- WebKitTools/GNUmakefile.am (revision 41443) > +++ WebKitTools/GNUmakefile.am (working copy) > @@ -7,8 +7,10 @@ > > # GtkLauncher > Programs_GtkLauncher_CPPFLAGS = \ > + -I$(srcdir)/WebCore/bindings \ > -I$(srcdir)/WebKit/gtk \ > -I$(top_builddir)/WebKit/gtk \ > + -I$(srcdir)/WebKit/gtk/webkit \ I don't think we need to add those two above. > @@ -31,8 +33,10 @@ > Programs_DumpRenderTree_CPPFLAGS = \ > -I$(srcdir)/WebKitTools/DumpRenderTree \ > -I$(srcdir)/WebKitTools/DumpRenderTree/gtk \ > + -I$(srcdir)/WebCore/bindings \ > -I$(srcdir)/WebKit/gtk \ > -I$(top_builddir)/WebKit/gtk \ > + -I$(srcdir)/WebKit/gtk/webkit \ Ditto. Thanks!

Jim Nelson

Comment 184 2009-03-09 18:43:09 PDT

(In reply to comment #183) > (From update of attachment 28381 [details] [review]) > Can we rename the build-related GOBJECT wording to GDOM i.e. GENSOURCESGOBJECT > -> GENSOURCESGDOM ? I don't think this makes sense for a couple of reasons. First, the general consensus is that we're moving away from GDOM as a prefix in the code, and that logically carries over to the makefile. Second, the other bindings are named after the language they are for (i.e. JS, ObjC, etc.) GObject is the best, all-encompassing name for these new bindings. > > # Script for creating hash tables > > @@ -103,7 +104,8 @@ > > -I$(srcdir)/JavaScriptCore/ForwardingHeaders \ > > -I$(srcdir)/JavaScriptCore/parser \ > > -I$(srcdir)/JavaScriptCore/wtf \ > > - -I$(top_builddir)/DerivedSources > > + -I$(top_builddir)/DerivedSources \ > > + -I$(srcdir)/WebCore/bindings/webkit > > No need to include .../bindings/webkit to the JSC build. Right. > > +webcoregtk_cppflags += \ > > + -I$(top_builddir)/DerivedSources/webkit \ > > + -I$(srcdir)/WebCore/bindings \ > > + -I$(srcdir)/WebCore/bindings/gobject > > + > > Please add the lines above to webcoregtk_cppflags in WebCore/GNUmakefile.am The flags need to be here for autogeneration and compilation. > Let's name the libtool archive to libWebCoreGDOM.la > Ditto and libwebcoregdom_h_api.Also declare libwebcoregdom_h_api before > libgobject_ladir above. Again, I believe GObject's a better choice. > > @@ -360,12 +372,14 @@ > > -I$(srcdir)/WebKit/gtk \ > > -I$(srcdir)/WebKit/gtk/WebCoreSupport \ > > -I$(srcdir)/WebKit/gtk/webkit \ > > - -I$(top_builddir)/WebKit/gtk/webkit > > + -I$(top_builddir)/WebKit/gtk/webkit \ > > + -I$(top_builddir)/DerivedSources > > Add DerivedSources/webkit here too. Right. > > @@ -466,6 +526,7 @@ > > # Build unit test > > noinst_PROGRAMS += Programs/UnitTests > > Programs_UnitTests_CPPFLAGS = \ > > + -I$(srcdir)/WebCore/bindings \ > > I don't think we need to include it. Right. > > @@ -494,7 +555,8 @@ > > $(webcore_built_sources) \ > > $(webcore_built_nosources) \ > > $(webkitgtk_built_sources) \ > > - $(webkitgtk_built_nosources) > > + $(webkitgtk_built_nosources) \ > > + $(gobject_built_nosources) > > gdom_built_sources. As explained above. > > webcore_cppflags += \ > > + -I$(srcdir)/WebKit/gtk \ > > + -I$(srcdir)/WebKit/gtk/WebCoreSupport \ > > + -I$(srcdir)/WebKit/gtk/webkit \ > Do we need to include WebKit here? Yes. > > @@ -57,6 +61,7 @@ > > DerivedSources/DocTypeStrings.cpp \ > > DerivedSources/tokenizer.cpp \ > > DerivedSources/ColorData.c \ > > + DerivedSources/webkit/webkitdomdummy.c \ > > This should go to gdom_built_nosources and please add it to BUILT_SOURCES too Again, as explained above. > > @@ -240,6 +245,14 @@ > > WebCore/xml/XMLSerializer.idl \ > > WebCore/xml/XSLTProcessor.idl > > > > +webcoregtk_sources += \ > > + WebCore/bindings/gobject/webkitbinding.cpp \ > > + WebCore/bindings/gobject/webkitbinding.h \ > > + WebCore/bindings/gobject/WebKitDOMObject.cpp \ > > + WebCore/bindings/gobject/WebKitDOMObject.h \ > > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp \ > > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.h > > Please add the sources above to webcoregtk_sources in line ~1730 > > Kindly rename GOBJECT to GDOM accordingly from here on (i.e. GOBJECT_AUTO_..., > GOBJECT_FIXED_..., GOBJECT_CLASSES, etc...) As explained above. > > +# All IDL files used for autogeneration in GObject. We filter out SVG and events for now. > > Please add a FIXME re SVG and events ^^^ - as we might need to add it later Right. > > +gobject_built_nosources := $(GOBJECT_HEADERS_BUILT) $(GOBJECT_SOURCES_BUILT) > > This should be _built_sources not _built_nosources. Why? > Please include the license header here. Added. > Why are the following lines prefixed with "webkit/"? We're already including > DerivedSources/webkit anyway. When headers are installed in the distribution, they'll wind up in the webkit/ directory (along with the WebKit/GTK header files). This is how the pathing worked in the earlier GTK code; we're just following along. > > # GtkLauncher > > Programs_GtkLauncher_CPPFLAGS = \ > > + -I$(srcdir)/WebCore/bindings \ > > -I$(srcdir)/WebKit/gtk \ > > -I$(top_builddir)/WebKit/gtk \ > > + -I$(srcdir)/WebKit/gtk/webkit \ > > I don't think we need to add those two above. Required for compilation. > > > @@ -31,8 +33,10 @@ > > Programs_DumpRenderTree_CPPFLAGS = \ > > -I$(srcdir)/WebKitTools/DumpRenderTree \ > > -I$(srcdir)/WebKitTools/DumpRenderTree/gtk \ > > + -I$(srcdir)/WebCore/bindings \ > > -I$(srcdir)/WebKit/gtk \ > > -I$(top_builddir)/WebKit/gtk \ > > + -I$(srcdir)/WebKit/gtk/webkit \ > > Ditto. Required for compilation. The ones I've marked "right" or "added" are straighforward enough, but it's not like the code doesn't build and execute without them. I'd like to get more input on this patch before I perform another one with these changes. -- Jim

Andre Klapper

Comment 185 2009-04-08 08:11:04 PDT

> I'd like to get more > input on this patch before I perform another one with these changes. Can someone comment?

Gustavo Noronha (kov)

Comment 186 2009-04-14 05:44:14 PDT

*** Bug 16686 has been marked as a duplicate of this bug. ***

Adam Dingle

Comment 187 2009-04-21 17:06:20 PDT

Created attachment 29670 [details] patch updated to revision 42662 Here's a new patch, updated for the latest WebKit nightly build (revision 42662). This patch contains no other changes since the last one posted (in comment #182). At this point I'm a bit perplexed as to what it will take to get this patch accepted. A little background: I work for Yorba, an open source group in San Francisco. We're working on (among other projects) a GTK-based WYSIWYG editor built on WebKit, and we're highly interested in a GTK DOM since we need it for our editor. My colleague Jim and I picked up work on this patch back in February, and submitted several successive iterations. We got great feedback from everyone until we posted our last version on March 6, but after that the thread has essentially gone dead for the last six weeks. I believe we've resolved every significant issue that has been raised (though please correct me if I'm wrong). Who will ultimately make the decision about when this patch is considered acceptable? It would help us if that individual or set of individuals could articulate what they're looking for. We're willing to make substantial further changes if desired. If the size of the patch is an issue, we could potentially even carve it into smaller iterations (for example, a first iteration could exclude exposing properties). We're also happy to come down to Cupertino to discuss in person if you're interested - we could discuss over lunch or in front of a whiteboard. As long as the patch remains unaccepted, we'll plan to continue to keep it alive via periodic postings here, though that certainly doesn't seem like the best possible outcome. Please let us know what more we can do - we're here to help!

Luke Kenneth Casson Leighton

Comment 188 2009-04-22 02:39:28 PDT

> At this point I'm a bit perplexed as to what it will take to get this patch > accepted. likewise. it's been nearly eight months since it was created. as a result of a lack of initiative from apple, i'm abandoning webkit in favour of gecko, having worked out that python-hulahop provides the missing link between gecko's DOM and python, in exactly the same way that [modified] pywebkitgtk provides python access to a DOM model. the advantages of using gecko is as follows: 1) it's fully de-facto standards-compliant. there has been active hostility towards making webkit language bindings fully de-facto standards compliance, with total and pathological silence as the answer when strong evidence is presented that webkit is the only web engine that fails to comply with modern de-facto standards. 2) it's a mature product gecko DOM interface bindings have been available for well over three years. despite the fact that there is so little documentation on it, and they're as obtuse as hell and so only a mother could love them, the gecko DOM interface language-independent bindings _do_ actually work, and finally the OLPC sugar team worked out how to use them (in python), and created python-hulahop overall, then, the possibilities for webkit are terminated by apple's intransigence and deliberate hostility towards de-facto standards compliance and support for the features that this patch provides. anyone reading this is advised think twice before using webkit until such time as apple get their act together. for example - to the gnome developers reading this: you made the right decision to pull webkit from epiphany and use gecko.

Xan Lopez

Comment 189 2009-04-22 03:08:25 PDT

Comment on attachment 29670 [details] patch updated to revision 42662 Marking the patch for review. You need to set the review flag to '?' for it to appear in the queue, that way it's easier for them to notice it. I'm trying to poke someone with experience in this area to look into this now, thanks for your efforts and patience :)

Mark Rowe (bdash)

Comment 190 2009-04-22 03:34:34 PDT

(In reply to comment #188) > > At this point I'm a bit perplexed as to what it will take to get this patch > > accepted. > > likewise. it's been nearly eight months since it was created. That's not at all accurate. It's been around two months since a patch that was in a reasonable state was uploaded. I can understand that it is disappointing that it hasn't been reviewed in the two months since. Personally, I hadn't seen this bug since it was updated in February as someone appears to have cleared or neglected to set the review flag on the most recent iteration of the patch, meaning that it dropped out of the review queue. If that is set once again then it should get a little more visibility. > as a result of a lack of initiative from apple, i'm abandoning webkit in favour > of gecko, having worked out that python-hulahop provides the missing link > between gecko's DOM and python, in exactly the same way that [modified] > pywebkitgtk provides python access to a DOM model. Great. I wish you the best of luck with Gecko, and I would encourage you to contribute to and enrich their project in similar manner to how you've contributed to and enriched WebKit. I also hope that this decision will cause you to cease adding further uninformed and inflammatory comments to this bug so that those who are actively working on improving WebKit can do so without having to wade through your ramblings. > there has been active hostility towards making webkit language bindings > fully de-facto standards compliance, with total and pathological silence > as the answer when strong evidence is presented that webkit is the only web > engine that fails to comply with modern de-facto standards. It is an intentional design decision to treat the JavaScript behavior as what is effectively a backwards-compatibility mode on top of the formal DOM standards. It's clear you don't agree with that decision, but it's ridiculous to claim that this somehow means we're failing to comply with standards. There are no backwards-compatibility constraints for non-JavaScript content, so there is nothing to comply with, and no compelling reasons to add additional baggage to new API. > overall, then, the possibilities for webkit are terminated by apple's > intransigence and deliberate hostility towards de-facto standards > compliance and support for the features that this patch provides. > > anyone reading this is advised think twice before using webkit until > such time as apple get their act together. I can't tell whether you're more upset by the fact the functionality isn't currently available in WebKit or that Apple drives core WebKit development but doesn't work directly on the GTK port. A lot of your rhetoric seems to completely ignore the actual points of discussion and instead focusses on assigning blame to Apple. That's an incredibly counter-productive approach to participating in any sort of useful discussion. > for example - to the gnome developers reading this: you made the right > decision to pull webkit from epiphany and use gecko. Yes, the Epiphany developers have clearly pulled WebKit and are using Gecko, as can be seen from the recent changes at <http://git.gnome.org/cgit/epiphany/log/>… … …

Mark Rowe (bdash)

Comment 191 2009-04-22 04:17:28 PDT

Comment on attachment 29670 [details] patch updated to revision 42662 > # Script for creating hash tables > @@ -110,7 +111,8 @@ javascriptcore_cppflags += \ > -I$(srcdir)/JavaScriptCore/ForwardingHeaders \ > -I$(srcdir)/JavaScriptCore/parser \ > -I$(srcdir)/JavaScriptCore/wtf \ > - -I$(top_builddir)/DerivedSources > + -I$(top_builddir)/DerivedSources \ > + -I$(srcdir)/WebCore/bindings/webkit This and other changes to the include search path are a little bit of a concern due to the layering violations they imply. JavaScriptCore should not depend on headers in WebCore. WebCore should not depend on headers from WebKit. > +webcoregtk_sources += \ > + WebCore/bindings/gobject/webkitbinding.cpp \ > + WebCore/bindings/gobject/webkitbinding.h \ > + WebCore/bindings/gobject/WebKitDOMObject.cpp \ > + WebCore/bindings/gobject/WebKitDOMObject.h \ > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp \ > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.h > + It looks like some of these files do not follow the naming convention. This should be addressed. > Index: WebCore/bindings/gobject/WebKitDOMObject.cpp > =================================================================== > --- WebCore/bindings/gobject/WebKitDOMObject.cpp (revision 0) > +++ WebCore/bindings/gobject/WebKitDOMObject.cpp (revision 0) > @@ -0,0 +1,28 @@ > +/* > + * Copyright (C) 2008 Luke Kenneth Casson Leighton <lkcl@lkcl.net> > + * Copyright (C) 2008 Martin Soto <soto@freedesktop.org> > + * Copyright (C) 2008 Alp Toker <alp@atoker.com> > + * Copyright (C) 2008 Apple Inc. All Rights Reserved. > + */ This file needs a license header. > +#include <glib-object.h> > + > +#include "config.h" > +#include "webkitbinding.h" > +#include "WebKitDOMObject.h" These includes should follow the order in the style guidelines (config.h, WebKitDOMObject.cpp, blank line, remaining includes in sorted order). > =================================================================== > --- WebCore/bindings/gobject/WebKitDOMObject.h (revision 0) > +++ WebCore/bindings/gobject/WebKitDOMObject.h (revision 0) > @@ -0,0 +1,56 @@ > +/* > + * Copyright (C) 2008 Luke Kenneth Casson Leighton <lkcl@lkcl.net> > + * Copyright (C) 2008 Martin Soto <soto@freedesktop.org> > + * Copyright (C) 2008 Alp Toker <alp@atoker.com> > + * Copyright (C) 2008 Apple Inc. All Rights Reserved. > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Library General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Library General Public License for more details. > + * > + * You should have received a copy of the GNU Library General Public License > + * along with this library; see the file COPYING.LIB. If not, write to > + * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, > + * Boston, MA 02110-1301, USA. > + */ > + > + > +#ifndef WebKitDOMObject_h > +#define WebKitDOMObject_h > + > +#include "glib-object.h" If this header is included here, why is it also included in WebKitDOMObject.cpp? Why does one place use "" while the other uses <>? > +#include "webkit/webkitdomdefines.h" > +#include <webkit/webkitdefines.h> Why does one of these includes use "" and the other <>? > +struct _WebKitDOMObject { > + GObject parent_instance; > + > + void *coreObject; > +}; > + > +struct _WebKitDOMObjectClass { > + GObjectClass parent_class; > +}; > + Some consistency on the naming style on these member variables would be nice. > Index: WebCore/bindings/gobject/gstringconvert.h This file name doesn't fit our naming conventions. > =================================================================== > --- WebCore/bindings/gobject/gstringconvert.h (revision 0) > +++ WebCore/bindings/gobject/gstringconvert.h (revision 0) > @@ -0,0 +1,37 @@ > +/* > + * Copyright (C) 2008 Luke Kenneth Casson Leighton <lkcl@lkcl.net> > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Library General Public > + * License as published by the Free Software Foundation; either > + * version 2 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Library General Public License for more details. > + * > + * You should have received a copy of the GNU Library General Public License > + * along with this library; see the file COPYING.LIB. If not, write to > + * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, > + * Boston, MA 02110-1301, USA. > + */ > + > + > +#ifndef GSTRING_CONVERT_H > +#define GSTRING_CONVERT_H > + > +/* convenience functions for converting various webkit string types into a utf8 glib string */ WebKit. > +#include "AtomicString.h" > +#include "CString.h" > +#include "KURL.h" > +#include "PlatformString.h" > +#include "unicode/ustring.h" Why is the unicode/ustring.h include necessary here? > +inline gchar * gdom_gstring_convert(WebCore::String const& s) { return g_strdup(s.utf8().data()); } > +inline gchar * gdom_gstring_convert(WebCore::KURL const& s) { return g_strdup(s.string().utf8().data()); } > +inline gchar * gdom_gstring_convert(const JSC::UString & s) { return g_strdup(s.UTF8String().c_str()); } > +inline gchar * gdom_gstring_convert(WebCore::AtomicString const&s) { return g_strdup(s.string().utf8().data()); } This doesn't follow our coding style. The spacing around operators is inconsistent, and the function names are using lower case with underscores. > Index: WebCore/bindings/gobject/webkitbinding.cpp > =================================================================== > --- WebCore/bindings/gobject/webkitbinding.cpp (revision 0) > +++ WebCore/bindings/gobject/webkitbinding.cpp (revision 0) > @@ -0,0 +1,367 @@ The file name doesn't fit our convention, and the include order in this file is a bit whacky. It should be updated to follow the style guidelines, with the duplicate headers removed. It may make sense to keep the generated headers in a separate block, but the others should follow the style. > +namespace WebKit { This seems a bit out of place inside WebCore, but perhaps it is intentional. > +#include <wtf/Noncopyable.h> > + > +#include "CanvasPixelArray.h" > +#include "CSSRule.h" > +#include "CSSValue.h" > +#include "Document.h" > +#include "DOMWindow.h" > +#include "Element.h" > +#include "HTMLCollection.h" > +#include "Node.h" > +#include "StyleSheet.h" > +#include "Text.h" Similar comment about includes here. > + > +namespace WebCore { > + > + class AtomicString; > + class Document; > + class Event; > + class Frame; > + class KURL; > + class Node; > + class String; Given some of the files that are included above, many of these forward declarations are redundant. > Index: WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp > =================================================================== > --- WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp (revision 0) > +++ WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp (revision 0) Is there some way we can autogenerate this file? It seems like it is almost entirely boilerplate. > + > +#include "glib-object.h" > +#include <wtf/Forward.h> > +#include "HTMLElement.h" > + > +namespace WebCore { > + class HTMLElement; > +} Including HTMLElement.h then forward-declaring HTMLElement is a bit redundant. > Index: WebCore/bindings/scripts/CodeGeneratorGObject.pm > =================================================================== > --- WebCore/bindings/scripts/CodeGeneratorGObject.pm (revision 0) > +++ WebCore/bindings/scripts/CodeGeneratorGObject.pm (revision 0) [ I'm skipping this file for now in hopes that I'll be able to convince Sam to look at it. ] > Index: WebCore/bindings/scripts/gobject-generate.pl > =================================================================== > --- WebCore/bindings/scripts/gobject-generate.pl (revision 0) > +++ WebCore/bindings/scripts/gobject-generate.pl (revision 0) It may make more sense for this to be named in the same order as the other "generate" script in that directory. > Index: WebKitTools/GNUmakefile.am > =================================================================== > --- WebKitTools/GNUmakefile.am (revision 42662) > +++ WebKitTools/GNUmakefile.am (working copy) > @@ -4,8 +4,10 @@ noinst_PROGRAMS += \ > > # GtkLauncher > Programs_GtkLauncher_CPPFLAGS = \ > + -I$(srcdir)/WebCore/bindings \ > -I$(srcdir)/WebKit/gtk \ > -I$(top_builddir)/WebKit/gtk \ > + -I$(srcdir)/WebKit/gtk/webkit \ > $(global_cppflags) \ > $(javascriptcore_cppflags) > > @@ -29,8 +31,10 @@ Programs_GtkLauncher_LDADD = \ > dumprendertree_cppflags := \ > -I$(srcdir)/WebKitTools/DumpRenderTree \ > -I$(srcdir)/WebKitTools/DumpRenderTree/gtk \ > + -I$(srcdir)/WebCore/bindings \ > -I$(srcdir)/WebKit/gtk \ > -I$(top_builddir)/WebKit/gtk \ > + -I$(srcdir)/WebKit/gtk/webkit \ > $(global_cppflags) \ > $(javascriptcore_cppflags) > DumpRenderTree should only be using API. It should not have any dependencies on WebCore. I'm going to mark this as r- for now and will try to review the remaining file shortly.

Xan Lopez

Comment 192 2009-04-22 04:27:55 PDT

> > +inline gchar * gdom_gstring_convert(WebCore::String const& s) { return g_strdup(s.utf8().data()); } > > +inline gchar * gdom_gstring_convert(WebCore::KURL const& s) { return g_strdup(s.string().utf8().data()); } > > +inline gchar * gdom_gstring_convert(const JSC::UString & s) { return g_strdup(s.UTF8String().c_str()); } > > +inline gchar * gdom_gstring_convert(WebCore::AtomicString const&s) { return g_strdup(s.string().utf8().data()); } > > This doesn't follow our coding style. The spacing around operators is > inconsistent, and the function names are using lower case with underscores. > BTW, I think I said this once already in the bug, but IMHO those functions sholdn't be prefixed with 'gdom', since they are not specific to the DOM bindings and could be used all over the GTK+ port code. Not sure what would be a good alternative, perhaps something like gwebcore or something...

Adam Dingle

Comment 193 2009-04-22 09:37:55 PDT

Thanks a lot for the feedback. We didn't realize about the review flag since we're new WebKit contributors, but we'll be sure to set it in the future. Some of the new points raised should be easy to fix and some might not be, but we'll ponder more and post again here soon.

Sam Weinig

Comment 194 2009-04-22 14:36:10 PDT

Comment on attachment 29670 [details] patch updated to revision 42662 I concur with Mark's review, this is not ready to be landed. I have gone through the CodeGenerator and picked out a bunch of issues that really stick out, but in general, I can't really review this as is. I believe the best way forward is for you to pick one file (say Node.idl) and get code generation working for it or a subset of it. The stripped down version of the code generator that can generate this one file will be a great jumping off point. I know this seems like a step backwards, but the current state of the patch is really not reviewable as is due to a lack of clarity in the code. The single patch is trying to do too many things at once. Here are some comments: > + if ($attribute->signature->extendedAttributes->{"Custom"} || > + $attribute->signature->extendedAttributes->{"CustomGetter"} || > + $attribute->signature->extendedAttributes->{"CustomSetter"}) { > + return 1; > + } [Custom] and related attributes are only used for implementing JS specific quirks and should not be needed for GObject bindings. > + if ($prop_type eq "stylesheets::MediaList" or > + $prop_type eq "CSSStyleDeclaration" or > + $prop_type eq "CSSVariablesDeclaration" or > + $prop_type eq "EventListener" or > + $prop_type =~ /Constructor$/ or Constructors are a JS only idiom. > + > +sub UsesManualToJSImplementation { ??? How is this related to GObject support? > + my $type = shift; > + > + # skipped out CanvasPixelArray - see JSCanvasPixelArrayCustom.cpp for why. > + return 1 if $type eq "Node" or $type eq "Document" or $type eq "HTMLCollection" or > + $type eq "SVGPathSeg" or $type eq "StyleSheet" or $type eq "CSSRule" or $type eq "CSSValue" or > + $type eq "Event" or $type eq "Element" or $type eq "Text"; > + return 0; > +} > + > +sub WritePrivateHeader { > + my $object = shift; > + my $class = shift; > + > + my $interfaceName = $class->name; > + my $className = GetClassName($interfaceName); > + my $filename = "$outputDir/" . $className . "Private.h"; > + my $guard = uc(decamelize($className)) . "_PRIVATE_H"; > + my $parentClassName = GetParentClassName($class); > + > + my $hasLegacyParent = $class->extendedAttributes->{"LegacyParent"}; LegacyParent is a JS only idiom. > + my $hasRealParent = @{$class->parents} > 0; > + my $hasParent = $hasLegacyParent || $hasRealParent; > + > + open(PRIVHEADER, ">$filename") or die "Couldn't open file $filename for writing"; > + > + print PRIVHEADER split("\r", $licenceTemplate); > + print PRIVHEADER "\n"; > + > + my $text = << "EOF"; > +#ifndef $guard > +#define $guard > + > +#include <glib-object.h> > +#include <webkit/${parentClassName}.h> > +#include "${interfaceName}.h" > +EOF > + > + print PRIVHEADER $text; > + > + print PRIVHEADER map { "#include \"$_\"\n" } sort keys(%hdrPropIncludes); > + print PRIVHEADER "\n" if keys(%hdrPropIncludes); > + > + $text = << "EOF"; > +typedef struct _${className} ${className}; > + > +namespace WebKit { > + ${className} * > + wrap${interfaceName}(WebCore::${interfaceName} *coreObject); > + > + WebCore::${interfaceName} * > + core(${className} *request); > + > +EOF > + > + print PRIVHEADER $text; > + > + if (${interfaceName} eq "DOMWindow" || (!$hasParent or $class->extendedAttributes->{"GenerateToJS"}) and > + !UsesManualToJSImplementation($interfaceName)) { > + $text = << "EOF"; What is this trying to do? > +sub Uniquify { > + my $name = shift; > + my $avoid = shift; > + if ($name eq $avoid) { > + $name = $name . "2"; > + } Please explain this. > + if($attribute->signature->extendedAttributes->{"ConvertFromString"}) { This is a JS idiom. > + # TODO: Add other conversion functions for different types. Current > + # IDLs only list longs. > + if($gtype eq "long") { > + $convert_fn = ""; > + $post_convert_fn = ".toInt()"; > + } else { > + die "Can't convert to type ${gtype}."; > + } > + } > + > + if ($gtype eq "int") { > + $txt_install_prop = << "EOF"; > + G_MININT, /* min */ > + G_MAXINT, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "boolean") { > + $txt_install_prop = << "EOF"; > + FALSE, /* default */ > +EOF > + } elsif ($gtype eq "float") { > + $txt_install_prop = << "EOF"; > + G_MINFLOAT, /* min */ > + G_MAXFLOAT, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "double") { > + $txt_install_prop = << "EOF"; > + G_MINDOUBLE, /* min */ > + G_MAXDOUBLE, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "uint64") { > + $txt_install_prop = << "EOF"; > + 0, /* min */ > + G_MAXUINT64, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "ulong") { > + $txt_install_prop = << "EOF"; > + 0, /* min */ > + G_MAXULONG, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "long") { > + $txt_install_prop = << "EOF"; > + G_MINLONG, /* min */ > + G_MAXLONG, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "uint") { > + $txt_install_prop = << "EOF"; > + 0, /* min */ > + G_MAXUINT, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "ushort") { > + $txt_install_prop = << "EOF"; > + 0, /* min */ > + G_MAXUINT16, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "uchar") { > + $txt_install_prop = << "EOF"; > + G_MININT8, /* min */ > + G_MAXINT8, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "char") { > + $txt_install_prop = << "EOF"; > + 0, /* min */ > + G_MAXUINT8, /* max */ > + 0, /* default */ > +EOF > + } elsif ($gtype eq "string") { > + $txt_install_prop = << "EOF"; > + "", /* default */ > +EOF > + } elsif ($gtype eq "object") { > + $txt_install_prop = << "EOF"; > + WEBKIT_TYPE_${propGType}, /* gobject type */ > +EOF > + } > + push(@txt_install_props, $txt_install_prop); > + $txt_install_prop = << "EOF"; > + (GParamFlags)${gparamflag})); > + > +EOF This should probably be done in a more generic way using a hash.

Adam Dingle

Comment 195 2009-05-01 15:57:58 PDT

Thanks again for all the feedback. Sam's comments above were sobering, and Jim and I used them for a starting point for a discussion about how to move forward. In our work in the last couple of months, we started with the existing patch and simply tried to fix things that were obviously broken, but as Sam pointed out the problem is that there's still an overwhelming amount of code that's poorly understood (even to us, who have been recently working on the patch). We now agree that a different approach is required. I'm convinced we should start over and work incrementally, pulling in pieces of the existing patch where appropriate. A great first iteration would be one which exposed only a couple of interfaces (perhaps Node and Document) and only a limited set of methods or attributes (perhaps, say, only attributes of type string; then at least we could write a test program that retrieved the current document's title). That might yield a patch of only a few hundred lines, which we could manageably review to ensure that it's solid. Great. We could commit that (possibly to a branch), then work on another patch which, say, extended the system to expose attributes of any primitive type. We could review and commit that, and so on. We believe this is the right way forward. Unfortunately, for entirely unrelated reasons our software group (Yorba) is focusing on other projects right now, and so while we'd love to contribute to this seemingly-unending GTK+/DOM effort, I think we may not the resources to do so in the next few months. It would be great if someone else wanted to continue the effort along the lines above, and if not I think it's quite likely we'll come back to this at some point, probably later this year.

Sean Neilan

Comment 196 2009-06-04 08:31:13 PDT

Hi, Is it possible for me at this moment to apply any of the above patches (if at all) and start manipulating the dom through something like pywebkitgtk? http://code.google.com/p/pywebkitgtk/issues/detail?id=13 Thank you very much for your time.

Leon Winter

Comment 197 2009-06-06 08:27:12 PDT

Hi, i just wanted to know if there is any progress on this issue. It would be a great benefit as an addition to the toolkit bindings. Since WebKit/GTK does not provide an interface to manipulate the DOM directly one has to use slow inline javascript. In my opinion this is a very important interface to enrich the browsers ability to provide the user more information and give them better control. Regards, Leon Winter

Sean Neilan

Comment 198 2009-06-06 11:23:23 PDT

(In reply to comment #197) Hey Leon, There's an unofficial patched version of webkit with the extensions you're looking for. http://wiki.github.com/lkcl/webkit/installing-webkit-glib-on-macosx I'm working on compiling it right now.

Luke Kenneth Casson Leighton

Comment 199 2009-06-07 01:53:31 PDT

(In reply to comment #86) > (In reply to comment #52) > > --- WebCore/page/DOMWindow.idl (revision 36459) > > +++ WebCore/page/DOMWindow.idl (working copy) > > @@ -155,7 +155,7 @@ > > [DoNotCheckDomainSecurity, Custom] void postMessage(in DOMString > > message, in DOMString targetOrigin) > > raises(DOMException); > > > > -#if defined(LANGUAGE_JAVASCRIPT) > > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT) > > // Global constructors > > attribute StyleSheetConstructor StyleSheet; > > attribute CSSStyleSheetConstructor CSSStyleSheet; > > > > i've added this in as a reminder that, at some point _in the future_, > > the gobject auto-generator code will need to auto-generate "constructors". > > i believe this was part of the problem i had in doing creation of a > > document - not having some of these functions. > > > > although it will be straightforward to add constructors, i'm not doing > > it for this patch. > > Constructors are JavaScript language concept. They're not something that other > bindings need to worry about. unfortunately, as has just been discovered, not having constructors, and making them "javascript language concept", means that certain objects and certain functionality can never be accessed. there is an implicit assumption that all functionality - all objects - can be accessed somehow as the return result of another function, where, absolute best case, you can have one and only one function at the top-level such as gdom_get_dom_window() and then access quite literally everything from there. unfortunately, that is not the case. "XPathNSResolver" is one object which is NOT returned as the return result from ANY other webkit DOM object function. in amongst the 450 or so webkit DOM objects, there will be several others. this is the primary reason why constructors were added to javascript, and you would do well to stop interfering with the development of the glib / gobject language bindings and start trusting the experience and process which created the javascript language bindings over several years. there are _good_ reasons why the javascript language bindings are the way that they are, and it's going to be _really_ fucking boring to have to justify at every single step of the way every single fucking feature again and again. a much simpler process is if you (apple) stop interfering and blocking development by trying to dictate what these glib / gobject language bindings _should_ have, according to some idealistic W3C standard instead of the de-facto real world javascript standard, and start trusting the judgement of the people who are actually _using_ these language bindings in the real world.

Luke Kenneth Casson Leighton

Comment 200 2009-06-07 08:50:13 PDT

rrright - time for a recap. * initial progress made was fast, fun, and useful. python bindings on top of the glib bindings (pywebkitgtk) and then a desktop widget API on top of that (pyjamas-desktop) allowed for rapid, full and nearly complete development of the glib / gobject bindings. about the only thing that was missed out was "remove event listener". mark and the other apple employees were extremely helpful in advising on key critical webkit issues, in particular refcounting, and in how the javascript and the objective-c bindings work, both of which were copied and learned from, to create the gobject bindings. * review was not done for several weeks because it was not understood that a "?" has to be put next to patches. * a review cycle began, which comprised several levels: 1) compliance with webkit coding standards. communication on exactly which parts of the coding standards were required to be complied with was in some cases not made explicit enough, but was eventually understood. 2) downright silly bugs - it's always good to find these. 3) an explanation of refcounting that was beyond the ability of three separate engineers to understand, and a request to comply with the c++ webkit standards on refcounting rather than the "mixed" manual approach, which the three separate engineers all attempted to implement, independently, without success 4) apple making it explicitly clear that compliance with de-facto (industry) standards must NOT be done; that even if it jeopardises developers' ability to utilise the gobject bindings and terminates any possibility that a project could ever make use of the gobject bindings, compliance with the W3C DOM standards is of absolute pathological and paramount absolute 100% top priority. * a request was made, by apple employees, to two separate engineers, to provide a much "simpler" patch - one which would help them to understand what was going on. the first engineer - a free software developer with debts approaching $USD 50,000 and with irregular income of only around $1000 per month - did some initial exploration into creating a "simpler" gdom patch (attempting to add GdomNode only) and found it to be a complex process that would by default pull in vast amounts of dependent objects (such as GdomNodeList, and then GdomAttr, and so on). actually creating a "simpler" patch that would compile and would be verifiable turned out to be too challenging. the request was therefore denied. the second request, made to a separate engineering team, was also denied on the basis of the team running out of time and money to spend [on educating apple employees as well as their own project]. in both cases, it was made very clear that billion dollar companies such as apple really shouldn't go asking for freebies, with the implication being that it is the responsibility of the webkit maintainers to take the time and utilise their own corporate money to understand what is going on, or, if that is not possible, to delegate responsibility to someone who _does_ understand. * the complexity of the patch began to take its toll, leading the apple engineers to begin to take drastic measures to try and reduce the amount of complexity that they had to be involved with, and thus reduce the amount of stress that they would face. one of the psychological methods deployed was to clearly and explicitly state a lack of trust in the original engineer's work, and to begin to belittle both the engineer and the project that had inspired the original gobject bindings work. the reaction of the engineer was one of frustration, disbelief and coarsely-expressed outrage, mixed in with attempts to provide reasonable counter-arguments to the increasingly hostile, increasingly disrespectful and increasingly non-technical or goal-post-moving arguments being dreamed up by apple engineers. the "arguments of last resort" being utilised by apple engineers were simply silence or to state "because we said so". thus, the opportunity for progress is terminated by a billion-dollar corporation. "because we said so". * contributions by other engineers were welcomed, mostly because the engineers, not having the practical experience of developing a fully-blown Widget API on top of the webkit / gobject bindings, acted according to apple's dictats. the original developer could no longer work with these engineers because of removal of critical functionality that left no way to do any testing (by running high-level test suites using the Widget API that was based on webkit/gobject). * suggestions to relax the coding standards and land the patch as-is, and then create much much simpler follow-up patches to correct any issues, and to use the webkit bugtracker to record outstanding issues, were dismissed out-of-hand. * research showing that the de-facto javascript standards are leading the way in all other language bindings in all other leading browser engine technology - MSHTML, KHTML, Gecko - has been ignored, despite five requests that apple employees review the researched material showing that webkit will be the only web browser engine in the world that does not comply with the de-facto javascript standards, thus making it incredibly awkward or literally impossible to use. * developers who are now beginning to utilise the glib / gobject bindings are finding that functionality which has been shown and proven to be required by the original engineer (which the apple employees refuse "because we said so" to accept) is actually, in fact... required! given this summary, suggestions on how to proceed, to provide a full set of glib / gobject language bindings, that provides a _useful_ and _useable_ set of language bindings, might be a good idea to discuss. a good way to begin might be for apple's webkit team to make a clear statement regarding their position on language bindings, and to clearly and unequivocably state whether it is apple's intent to dominate, dictate and stifle development or whether it is their intent to act as a facilitator and accelerator of the development and the reach of this strategically important piece of software.

David Kilzer (:ddkilzer)

Comment 201 2009-06-07 15:30:10 PDT

(In reply to comment #200) > * review was not done for several weeks because it was not understood that a > "?" has to be put next to patches. Information about how to contribute to WebKit has been on the web site for a long time: http://webkit.org/coding/contributing.html > * a review cycle began, which comprised several levels: > > 1) compliance with webkit coding standards. communication on exactly which > parts of the coding standards were required to be complied with was in some > cases not made explicit enough, but was eventually understood. Coding style has similarly been documented on the web site for a long time: http://webkit.org/coding/coding-style.html > 3) an explanation of refcounting that was beyond the ability of three separate > engineers to understand, and a request to comply with the c++ webkit standards > on refcounting rather than the "mixed" manual approach, which the three > separate engineers all attempted to implement, independently, without success More about ref counted variables is available here. It's not linked from other pages on the site, but it's available via direct link and has been committed to the svn repository for a while now: http://webkit.org/coding/RefPtr.html The rules for how to use RefPtr and PassRefPtr really do make sense once you understand what they're doing. It took me a while to fully understand the pattern, and it definitely helped me to read through this document more than once. > * a request was made, by apple employees, to two separate engineers, to provide > a much "simpler" patch [...]. > > the "arguments of last resort" being utilised by apple engineers were simply > silence or to state "because we said so". Everyone who contributes patches to the project must follow the same process. That includes making their patches of reasonable size and complexity for reviewers to understand and comment on (and breaking them up if necessary), following the coding style guidelines and writing regression tests whenever possible. Why do you feel that this particular patch does not need to follow that process?

Mark Rowe (bdash)

Comment 202 2009-06-07 22:00:52 PDT

(In reply to comment #199) > "XPathNSResolver" is one object which is NOT returned as the return > result from ANY other webkit DOM object function. <http://trac.webkit.org/browser/trunk/WebCore/dom/Document.idl#L124>

Luke Kenneth Casson Leighton

Comment 203 2009-06-08 02:12:51 PDT

> Everyone who contributes patches to the project must follow the same process. > That includes making their patches of reasonable size and complexity for > reviewers to understand and comment on (and breaking them up if necessary), > following the coding style guidelines and writing regression tests whenever > possible. 1) coding style guidelines i perfectly understand and accept. where it has been possible to understand what is being requested, and where, in amongst what is now 200 messages i have been able to _find_ the requests, i have complied, because i understand completely the value of coding style guidelines. 2) the available testing resources - and the available _time_ to _create_ tests - are limited. the process by which the work was done and tested was by utilising an empirical high-level process. i apologise for not having enough time and not enough money to spend on creating better, more acceptable test resources. the testing and development process involves use of pywebkitgtk (an intermediate library) and pyjamas-desktop (a high-level API). by comparing and observing the results of the operation of the 20 or so applications under the pyjamas-desktop API against the "original" (pyjamas), i was able to empirically gain a level of confidence that the work actually performed as expected. [attempts to recommend this process of testing to the webkit developers were met with scorn and derision, dismissed out of hand, being described as a "pet project". such belittlement of an empirical and comprehensive test process is wildly inappropriate, as well as being part of an inappropriate personal attack]. i mention this because just because this empirical test process is "different", it doesn't make it "invalid". if i had available time and money, i would go create some reassuring unit tests. i apologise for being a free software developer who does not have access to unlimited funds. i made the decision to bypass unit tests on the gdom_ code and even on pywebkitgtk because i _trust_ the process which created glib and i _trust_ the process by which codegen.py in the well-established python-gobject project auto-generates python bindings. so i saw no need to go reinventing the test process, and went direct to a much more overall useful empirical test process. that this process involves projects and code that are not part of the core of webkit is, to be blunt, not my problem. > Why do you feel that this particular patch does not need to follow that > process? david, thank you for asking that question. parts of the answer have already been made, a number of times, but i am happy to reiterate them here, and i trust that you are asking this question in order to take this matter seriously, and i trust that you will give the reasons outlined below serious consideration. 1) the development of this work was a highly complex one-off that required approx eight weeks of 11 hour days in order to complete _without_ losing track of what was involved. hundreds of classes required memorisation (which could not have been done on a part-time basis or over a longer time period); approximately 250 simultaneous editor sessions were needed, at one point, to keep track of related files. requests to "fit in" with a "simpler" process were, and are, therefore simply not practical, on a task that was, and is, already monstrously complex. one attempt was made (GdomNode), and it became immediately clear that it would pull in vast amounts of extra code and classes - GdomNodeList, GdomAttr and more). a second independent engineering team were also requested to create a "simpler" patch: the request by apple for _their_ time and resources to be spent was _also_ denie. the work has therefore been done, i apologise, as pretty much a one-off "fait-accomplit"; for this reason alone, it should be accepted as-is and then worked on, slowly, in manageable chunks, to fix any known issues. one other independent engineering team has already given up on trying to "fit in" with the process; this should emphasise and highlight to you that this is not .... see inappropriate and disrespectful accusations, in this, 2nd from last paragraph: https://bugs.webkit.org/show_bug.cgi?id=16401#c70 2) keeping track of issues has proven to be a nightmare (which i predicted it would be, very early on) and the reviewers have repeatedly expressed frustration at their comments being "ignored" when in fact they were simply _not seen_ because there is _too much_ for one bug-tracker thread to handle. and the reason for there being "too much" is: see 1), above. you can see evidence of the frustration of the reviewers in their use of language to diminish the value of the work carried out, in beginning to utilise non-technical and non-strategic arguments, and in ignoring repeated requests for comments, in an attempt to reduce stress levels. there is a well-known and proven process by which the project can be made more manageable: the use of a bugtracker and the use of patches. however, it is not possible to have a bugtracker-within-a-bugtracker, and it extremely impractical to use patches-to-patches, and to consider developing a bugtracker-within-a-bugtracker and a patch-to-patch system _just_ for this one-off work would be a waste of developer resources. i started using github as a substitute but that is a "non-authoritative" source which is being ignored. for _this_ reason alone, it seems pretty obvious that the solution is to utilise the existing resources in the best way that they are intended - by creating smaller individual patches and having separate manageable bugreports. _but_, of course, that means that the work has first to be accepted. attempts to utilise the bug tracker to keep track of issues that need to be resolved in the patch itself (#20897, #20898) were requested to be terminated (ironically to avoid confusion). 3) the glib / gobject language bindings do not impact on the core webkit functionality in any way, shape or form. why therefore should apple _care_ about them? apple has its objective-c bindings. apple has its own port of webkit. so for goodness sake stop being obstructive and stand aside; make your own lives easier and let those people who _do_ care about the glib / gobject bindings be able to cooperate and collaborate on the development and progression of this strategically important functionality. _without_ interference. i fully appreciate and understand that it is desirable to stick to a known, tried and tested development path and process. however, unfortunately, sometimes with something as comprehensive as what has been created, in this instance, the easiest development process for the work itself _isn't_ necessarily the easiest thing to fit into the nice safe cosy comfortable practices. last but not least, in answer to your question, is this: look at the dates on CodeGeneratorJS.pm, CodeGeneratorCOM.pm and CodeGeneratorObjC.pm. they all state Copyright 2006. that means that those code generators have had _three_ years in which to go through an incremental (viz: "safe") development process, and it is the glib / gobject bindings which were left behind. a catch-up had to happen, and it was done in a mere eight weeks out of necessity. tell me you don't _seriously_ expect any free software developer willing to create glib / gobject bindings to go through some "nice", "safe", "apple-satisfying" development process, to create some half-baked unusable bits of code _just_ so that apple employees can get "up to speed" on how that development occurred? i trust that that's not what's being requested. i trust that apple is not asking free software developers to spend their time and resources on educating apple employees on the workings of these glib / gobject bindings. now. having said that, here are some issues which this work has raised, which need to be properly addressed, ideally before proceeding with this one-off work being merged "as-is" as a one-off exception into the svn repository: 1) all independent issues raised need to be created as separate bugreports (suggestion: dependent on this one, to keep track of them) preferably _before_ the work is merged. 2) the _strategic_ issues raised by this work need to be discussed, and arguments involving sentences with the words "apple's vision for webkit language bindings" will not be a part of that discussion. apple is _not_ the de-facto dictatorial decision maker for language bindings to something as strategically important as webkit. the research material (listed in this bugreport and requested to be reviewed _five_ times) showing that webkit will be left behind if apple's dictats are obeyed _will_ be investigated and discussed, amongst other things. i trust that you will give these matters serious consideration. i trust that the time and resources already wasted by not listening to my advice earlier can be clearly seen as an example of _why_ i advised that this work be accepted as-is, and that further time and resources need not be wasted. i trust that you can see this clearly and that it is long overdue to move on to much more exciting and adventurous issues such as adding SVG support and bindings to HTML5 features.

Luke Kenneth Casson Leighton

Comment 204 2009-06-08 02:21:10 PDT

(In reply to comment #202) > (In reply to comment #199) > > "XPathNSResolver" is one object which is NOT returned as the return > > result from ANY other webkit DOM object function. > > <http://trac.webkit.org/browser/trunk/WebCore/dom/Document.idl#L124> *double-take...* ok - ah, drat, sorry sorry, mark: i meant XPathEvaluator. lkcl@gonzalez:/var/src/WebKit$ grep XPathEvaluator */*/*.idl WebCore/dom/Document.idl: // DOM Level 3 XPath (XPathEvaluator interface) WebCore/page/DOMWindow.idl: attribute XPathEvaluatorConstructor XPathEvaluator; WebCore/xml/XPathEvaluator.idl: interface [GenerateConstructor, CanBeConstructed, Conditional=XPATH] XPathEvaluator { lkcl@gonzalez:/var/src/WebKit$ grep XPathEvaluator */*/*.idl */*/*/*.idl WebCore/dom/Document.idl: // DOM Level 3 XPath (XPathEvaluator interface) WebCore/page/DOMWindow.idl: attribute XPathEvaluatorConstructor XPathEvaluator; WebCore/xml/XPathEvaluator.idl: interface [GenerateConstructor, CanBeConstructed, Conditional=XPATH] XPathEvaluator { WebKit/win/Interfaces/DOMWindow.idl: //attribute XPathEvaluatorConstructor XPathEvaluator; regardless - thank you for highlighting this function: it's prompted me to review things more closely, and it looks like leon's just using gdom_x_path_evaluator_create_ns_resolver in the wrong way. appreciated. l.

Kalle Vahlman

Comment 205 2009-06-08 03:04:23 PDT

(In reply to comment #203) > 1) coding style guidelines i perfectly understand and accept. where it has > been possible to understand what is being requested, and where, in amongst what > is now 200 messages i have been able to _find_ the requests, i have complied, > because i understand completely the value of coding style guidelines. [snip] > 2) keeping track of issues has proven to be a nightmare (which i predicted it > would be, very early on) and the reviewers have repeatedly expressed > frustration at their comments being "ignored" when in fact they were simply > _not seen_ because there is _too much_ for one bug-tracker thread to handle. > > and the reason for there being "too much" is: see 1), above. Noteworthy point here is that you are responsible for over 100 of those 200 messages, and quite likely more than 75% of the overall amount of text in the comments. So you are basically claiming that because you obfuscated the review process with long-winded rants about why you are right and others wrong, you get a free pass for your code. Why not just split out the controversial bits of the patch (like the de-facto standard features that you so crave) to get it reviewed and committed? Compared to the current strategy of throwing yourself to the ground and kicking and screaming until it happens, I wager it would even have chances of success.

Luke Kenneth Casson Leighton

Comment 206 2009-06-08 04:21:39 PDT

(In reply to comment #205) > (In reply to comment #203) > > and the reason for there being "too much" is: see 1), above. > > Noteworthy point here is that you are responsible for over 100 of those 200 > messages, and quite likely more than 75% of the overall amount of text in the > comments. this should give you an indication of the complexity of the process involved in the development of this work. it should also show you the lengths to which i was prepared to go to educate people on request. much also of the comments show my shock and confusion at being both personally insulted by respected members of free software communities, and at the way in which the advancement of free software's strategic reach is being jeapordised by bloody-mindedness. it should also indicate the respect that i have for people who are patient enough to provide valuable technical input, even in the face of an increasingly stressful process, and even whilst at the same time teaching them (with unfortunately very harsh lessons) to be a tiny bit more cooperative and collaborative in the _strategic_ development and direction of webkit. > So you are basically claiming that because you obfuscated the review process > with long-winded rants about why you are right and others wrong, you get a free > pass for your code. couple of things: 1) does the above paragraph contribute to the project or does it aggravate it? i would say that it both aggravates the project and also once again borders on personal insult instead of adding technical or strategic value. please can i respectfully request that you refrain from making comments that aggrave the project. please refrain from making comments that border on personal insult. 2) http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation correlation does not imply causation. that there exists 200 comments does not imply the insulting conclusion that you deduce. please refrain from wasting people's time with unfounded personal accusations and zero technical or strategic merit. > Why not just split out the controversial bits of the patch (like the de-facto > standard features that you so crave) to get it reviewed and committed? 1) pay me money, and i'll do exactly as you wish. 2) if you don't pay me money, fee free to contribute to the project rather than aggravate it. 3) why don't _you_ split out the controversial bits of the patch that you claim that i crave. 4) please refrain from making personal insults 5) please read http://en.wikipedia.org/wiki/Egoless_programming 6) please refrain from making assumptions that there are personal issues involved in the development of this work. you know _nothing_ about me, my goals or my vocation. > Compared to the current strategy of throwing yourself to the ground and kicking > and screaming until it happens, I wager it would even have chances of success. again - as yourself this question: "does the above paragraph contribute to the project or does it aggravate the project?" please refrain from making statements that aggravate the project. can i ask the maintainers of this bugtracker if they could please delete #205 (and also this message) from the bugtracker: #205 contributes no value to patch #16401.

Kalle Vahlman

Comment 207 2009-06-08 08:32:08 PDT

(In reply to comment #206) > > Noteworthy point here is that you are responsible for over 100 of those 200 > > messages, and quite likely more than 75% of the overall amount of text in the > > comments. > > this should give you an indication of the complexity of the process involved > in the development of this work. > > it should also show you the lengths to which i was prepared to go to educate > people on request. I don't think they asked for education. Furthermore, I'm pretty sure they understood the situation with W3C DOM, JS extensions to it and their adoption to the patch quite early so most of the repetetive commentary about the JS-specific features (starting around comment #88) were not needed. > much also of the comments show my shock and confusion at being both personally > insulted by respected members of free software communities, and at the way in > which the advancement of free software's strategic reach is being jeapordised > by bloody-mindedness. Free software allows you to take the code, modify and distribute it. So if you think WebKit is disfunctional wrt advancement of free software's strategic reach, you might want to fork the project to accommodate this. That way you not bound by the processes and infrastructure of the current project maintainers. > it should also indicate the respect that i have for people who are patient > enough to provide valuable technical input, even in the face of an increasingly > stressful process, and even whilst at the same time teaching them (with > unfortunately very harsh lessons) to be a tiny bit more cooperative and > collaborative in the _strategic_ development and direction of webkit. From the comments in this bug I get the impression that they indeed have a strategy, and you just don't agree with it. Which is naturally ok, as is the project maintainer's right to only accept code which implements *their* strategy. > > So you are basically claiming that because you obfuscated the review process > > with long-winded rants about why you are right and others wrong, you get a free > > pass for your code. > > couple of things: > > 1) does the above paragraph contribute to the project or does it aggravate it? > i would say that it both aggravates the project and also once again borders on > personal insult instead of adding technical or strategic value. I simply disagree with your assertion that the task is inherently so overwhelming that it should not be subjected to the review process. I also disagree that the amount of "comment spam" in this bug (most of it by you, mind you) would be another reason not to make sense of the patch before landing it. There is a good example of a too-large-to-handle patches and how to resolve the issue in the Glib Unicode bug: http://bugs.webkit.org/show_bug.cgi?id=15914 There the patch was after multiple rounds split and now the first ones are in. That would be how this work should evolve too. > please can i respectfully request that you refrain from making comments that > aggrave the project. > > please refrain from making comments that border on personal insult. If my tone was too personal for you, I apologize. > 2) http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation > > correlation does not imply causation. that there exists 200 comments does not > imply the insulting conclusion that you deduce. I have read each comment so my conclusions are not made by statistics of the commentary but also by the content therein. In fact, please refrain from making assumptions that I made my comments without understanding the issues concerning this bug and how to resolve it. Throwing wikipedia links to fancy terms and concepts that you seem to assume I don't know feels like questioning my intelligence and intent. > > Why not just split out the controversial bits of the patch (like the de-facto > > standard features that you so crave) to get it reviewed and committed? > > 1) pay me money, and i'll do exactly as you wish. I would, if it would be valuable enough for me to get this functionality in. It is not. > 2) if you don't pay me money, fee free to contribute to the project rather > than aggravate it. > > 3) why don't _you_ split out the controversial bits of the patch that you > claim that i crave. I've wanted to help with this feature, but unfortunately lack proper time for it currently. :(

Luke Kenneth Casson Leighton

Comment 208 2009-06-08 10:25:21 PDT

> If my tone was too personal for you, I apologize. thank you - that makes a big difference. i'm sorry if i jumped to conclusions ( i'll respond out of order with the rest as i wanted to say that first ). regarding your offer to help if you had time - that's really appreciated, too. i can recommend staying well clear, however, unless you have significant time available (or, as you say, a good reason). goodness knows where martin got his expertise from to be able to tackle this and rework it in the short amount of time that he did, but dang i have an enormous amount of respect for him for his contribution. i looked at #15914, and it would be a good idea to follow that example - i see that the functionality that was added fitted into four patches, two of which were dependent on the other. whilst it seems a very good approach to take, the difference between the two is that the unicode update _did_ fit into (roughly equally sized?) separate patches, and the glib/gobject bindings... well... here's reasons against the idea (even though it's a good one): 1) in the case of CodeGeneratorGObject.pm, virtually all of the functionality that's in there is required to support even just _one_ class, and the inter-dependence between the DOM classes makes - made - it pretty impractical to consider filtering them out. even if you want to do something as basic as "Node" - to create GdomNode - take a look at Node.idl, you can see _whoa_, it depends on Object, NodeList, EventTarget, EventListener, Document, NamedNodeMap - i just... gahh, the thought of in other words, the code, thanks to the inter-relationships between the DOM classes is a self-testing tangly mess that if you pull away one brick, the whole lot comes crashing down, and is sufficiently non-functional as to make testing impossible. put that another way: the set of objects which are inter-dependent to the extent where you can get something useful to test requires so much code-generation that you really aren't saving very much by even bothering to remove even 98% of the classes. the core - Window, Document, Node, Element, NodeList, Attr etc. - is _that_ inter-related. 2) i've gone well beyond the stage where "re-visiting" this code is something that i would relish. i'm happy with it. it works. it's a tangly mess of spaghetti perl - my least favoured language - and i'd rather cut my arms off and use my nose to type on keyboards for the rest of my life than get involved in significant rewrites (no offense intended at your preferred choice of code-generating language, alp :) i'd found myself doing the coding equivalent of holding my breath, waiting for the tangly mess of interdependencies to resolve into something - _anything_ that i could consistently compile - and it was a good... ten or so days before that happened. the HTML elements i initially skipped; property getters and setters i could skip [but couldn't test anything until they were added]. so - if someone _else_ would like to split this work up into smaller patches - _great_ - but count me out, big-time (except for advice). regarding the fork idea: i already have (by default): http://github.org/lkcl/webkit/tree/16401.master i needed a revision control system; i needed to be able to publish this to people who are using it. so far i've managed to do only about two svn catching-up updates since august 2008 (am in the middle of another one, right now) as they tend to take about three to four days, each. that's not a good situation for the people who are reliant on that code. so what's the alternative? well, we can sit and wait for someone else to come forward, someone with time and resources of about two to three full-time months, who has the patience to work through this and create smaller patches. ... but any corporation that looks at the tangly mess is much more likely to go, "hmmm, that code on github works, let's just use it, as-is, instead". and we've already _had_ one independent set of developers take a stab at "simplifying" things, to the extent where i couldn't get involved, because too much was missing - none of the pyjamas-desktop test suites or examples would work. > From the comments in this bug I get the impression that they indeed have a > strategy, and you just don't agree with it. the strategy is to restrict language bindings tightly to the provably-broken W3C standard, which _nobody_ - not one single browser technology group - has _ever_ implemented as-is (not even webkit). _everybody_ throws in exceptions and differences. so the "strategy" begins to look less like a "strategy" and much more like goal-post-shifting hypocrisy. if one feature should not be added to GObject bindings because it is not in the W3C standard, then _all_ features must be removed that do not fit into the W3C standard. if one feature is allowed (contrary to the W3C standard) because it is "useful" to some people, then to deny other features on some arbitrary basis that it is "that guy whom we have no respect for, what's his name, i'm trying to forget" who is recommending them is... what's the word... apartheid was based on it... not racism... huh. word escapes me. the one where you have one rule for one person or group, and another rule for another group. "discrimination". that's the word i was looking for. so. i want answers. i want the evidence shown in the research to be reviewed, and answers provided as to how the evidence presented fits in with apple's strategy for webkit. i've asked about seven times for a response, so far. > Which is naturally ok, as is the > project maintainer's right to only accept code which implements *their* > strategy. which is why i'm giving serious consideration to advocating the creation of a webkit software foundation, where control is specifically taken _away_ from apple as the sole and exclusive controller, and handed to a foundation which has technical _and_ strategic merit for submissions at its core (the apache foundation considered adding "strategic" merit to their charter, alongside "technical" merit, after some discussions several years ago). but that's getting off-topic. *acch, tch*. i just want to get on and for things to move forward, i'm fed up with this stupid unnecessary blocking of progress. i want people to be able to use webkit in lots more free software projects, in lots more programming languages and development environments than they are restricted to using at the moment, that's the whole damn reason why i chose this work, the glib bindings, in the first place - to open up webkit's strategic reach and to _help_ people.

Mark Rowe (bdash)

Comment 209 2009-06-08 20:45:35 PDT

Did you seriously just try and draw a parallel between apartheid and this patch? *Wow*.

David Kilzer (:ddkilzer)

Comment 210 2009-06-08 23:37:07 PDT

(In reply to comment #203) > > Why do you feel that this particular patch does not need to follow that > > process? > > david, thank you for asking that question. parts of the answer have already > been made, a number of times, but i am happy to reiterate them here, and i > trust that you are asking this question in order to take this matter seriously, > and i trust that you will give the reasons outlined below serious > consideration. It was a serious question, yes. > the work has therefore been done, i apologise, as pretty much a one-off > "fait-accomplit"; for this reason alone, it should be accepted as-is and then > worked on, slowly, in manageable chunks, to fix any known issues. Although I have NOT read all the comments in this bug, I'm going to assume you've done a fair job of summarizing them repeatedly in recent comments. To reiterate your position: - You believe the patch should be landed as-is, then iterated upon. - You don't have time to break up the patch into smaller pieces. The reviewer(s) have said: - The patch must be broken up into smaller pieces before being reviewed further. I think the important take-away here is that no one has stated that the patch may never be landed, just that it needs to be broken up, reviewed and landed in pieces. I'm not sure there's much more to say at this point until you (or someone else) can find more time to work on breaking up the patch.

Gour

Comment 211 2009-07-08 08:49:29 PDT

Hi! (In reply to comment #210) > The reviewer(s) have said: > > - The patch must be broken up into smaller pieces before being reviewed > further. > > I think the important take-away here is that no one has stated that the patch > may never be landed, just that it needs to be broken up, reviewed and landed in > pieces. > > I'm not sure there's much more to say at this point until you (or someone else) > can find more time to work on breaking up the patch. I understand that reviewer(s) want smaller pieces, but afaics, Luke is proving his dedication to provide solution for the real problem by providing code, i.e. putting his real hours into coding, and it would be, imho, fair that the patch is allowed into the codebase and then reviewed afterwards. The present situation is lose/lose - the codebase is missing functionality - complete DOM bindings - which nobody else wants to or has time to provide, while the end-users are also left in despair forcing them to go somewhere else :-( Sincerely, Gour (aka: end user being thrilled with the prospect of running the same code in browser as well on the desktop by the grace of pyjamas-project.)

Luke Kenneth Casson Leighton

Comment 212 2009-07-08 09:12:08 PDT

(In reply to comment #209) > Did you seriously just try and draw a parallel between apartheid and this > patch? *Wow*. no, i simply describe how the statements made, such as these: > the reasons that you made the changes in > many cases do not align with the WebKit project's vision for native bindings. are perceived by those on the "outside". the recipients of these dictatorial "visions". now. may i respectfully request, for the ninth time, that you review the research material that is in response to the dictatorial decision to follow strict W3C compliance rather than de-facto javascript standards? if you reveiw the research material that i spent several hours searching for, and make some comments on it, then you will see that it conflicts with this "vision" and you will have entered into a dialog that is forward-moving and inclusive, and thus can no longer be classified as "fascist". simple.

Luke Kenneth Casson Leighton

Comment 213 2009-07-08 09:33:04 PDT

(In reply to comment #210) > (In reply to comment #203) > > > Why do you feel that this particular patch does not need to follow that > > > process? > > > > david, thank you for asking that question. parts of the answer have already > > been made, a number of times, but i am happy to reiterate them here, and i > > trust that you are asking this question in order to take this matter seriously, > > and i trust that you will give the reasons outlined below serious > > consideration. > > It was a serious question, yes. ok, great. > > the work has therefore been done, i apologise, as pretty much a one-off > > "fait-accomplit"; for this reason alone, it should be accepted as-is and then > > worked on, slowly, in manageable chunks, to fix any known issues. > > Although I have NOT read all the comments in this bug, I'm going to assume > you've done a fair job of summarizing them repeatedly in recent comments. To > reiterate your position: > > - You believe the patch should be landed as-is, then iterated upon. i believe that that is a realistic and pragmatic approach. > - You don't have time to break up the patch into smaller pieces. ... and neither do the other people who have worked on it, see: https://bugs.webkit.org/show_bug.cgi?id=16401#c195 also neither will, i believe anybody else be willing to break it up; because DOM is so entangled that to even _begin_ unravelling it is tricky. > The reviewer(s) have said: > > - The patch must be broken up into smaller pieces before being reviewed > further. > > I think the important take-away here is that no one has stated that the patch > may never be landed, just that it needs to be broken up, reviewed and landed in > pieces. that is extremely unlikely to happen. from a "high level", using empirical testing and using pyjamas-desktop, the patch can be proven and demonstrated to work, and provide the necessary functionality. two separate contributors (myself and also martin) utilised this "indirect" method of testing (using pywebkitgtk) to verify and validate that the code works. > I'm not sure there's much more to say at this point until you (or someone else) > can find more time to work on breaking up the patch. trust me on this when i say that after two separate groups' valuable time has been wasted on trying to fulfil reviewers' decisions that you are extremely unlikely to find any further contributors with the skills and the time to do any further work. i'm deeply impressed by martin and adam's contributions and attempts to work with the reviewers, but the skills and time required to handle over 600 auto-generated files is just... too much for free software resources to handle. and it's _this_ that you will, ultimately, come to realise, and you will, eventually, come to a pragmatic decision. it make take another 100 comments; it may take another year... so. i will continue to refer people to this bug report, asking them to make their views known on this decision. when the number of comments gets to 250+ and you simply get sick to the back teeth of saying "no! our rules are more important than progress!", and you decide to land this patch (or whatever revision i have at the time) as-is, do contact me, and i will be delighted to help you and other contributors to create smaller (and for them more manageable) patches that will bring the code back into line with the strict coding standards. lastly: before anyone decides that they want to criticise me for the above, bear in mind this: i have the skills to patch any code that i want to, to do what i want, how i want. i can indefinitely maintain patched versions of webkit, patched versions of XULrunner, patched versions of pywebkitgtk. NOT EVERYONE has the time or resources or the confidence to do that. and the reason why i am not letting you - apple - get off the hook on this one is for THEIR benefit, NOT mine. so - do you, apple, want to help serve the free software community? or you want to serve yourselves?

David Kilzer (:ddkilzer)

Comment 214 2009-07-08 12:56:10 PDT

(In reply to comment #213) > (In reply to comment #210) > > Although I have NOT read all the comments in this bug, I'm going to assume > > you've done a fair job of summarizing them repeatedly in recent comments. To > > reiterate your position: > > > > - You believe the patch should be landed as-is, then iterated upon. > > i believe that that is a realistic and pragmatic approach. > > > - You don't have time to break up the patch into smaller pieces. > > ... and neither do the other people who have worked on it, see: > > https://bugs.webkit.org/show_bug.cgi?id=16401#c195 > > also neither will, i believe anybody else be willing to break it up; > because DOM is so entangled that to even _begin_ unravelling it is > tricky. > > > The reviewer(s) have said: > > > > - The patch must be broken up into smaller pieces before being reviewed > > further. > > > > I think the important take-away here is that no one has stated that the patch > > may never be landed, just that it needs to be broken up, reviewed and landed in > > pieces. > > that is extremely unlikely to happen. > > from a "high level", using empirical testing and using pyjamas-desktop, > the patch can be proven and demonstrated to work, and provide the > necessary functionality. > > two separate contributors (myself and also martin) utilised this "indirect" > method of testing (using pywebkitgtk) to verify and validate that the code > works. After re-reviewing some of the comments, I think my comment that the patch "must be broken up in to smaller pieces" may be worded too strongly. In Comment #76, breaking up the patch is suggested as a best practice for new contributors and will lead to quicker turnaround (reviews) on posted patches, but it's not a strict requirement. However, since you're unwilling to break it up (and since willing to be patient), the next step would be to post a new monolithic patch for review addressing feedback in Comment #191 and Comment #194.

Luke Kenneth Casson Leighton

Comment 215 2009-07-08 14:17:10 PDT

> After re-reviewing some of the comments, I think my comment that the patch > "must be broken up in to smaller pieces" may be worded too strongly. In > Comment #76, breaking up the patch is suggested as a best practice for new > contributors and will lead to quicker turnaround (reviews) on posted patches, > but it's not a strict requirement. ah, whew, that's a relief. > However, since you're unwilling to break it up it's more than that, it's that by doing so i cannot make any guarantees that the individual portions are either correct or actually do anything. it was only by having pretty much absolutely everything that i could get pyjamas-desktop to work, and thus run the high-level tests (pyjamas examples, pyjamas unit tests etc.) > (and since willing to be patient), got all the time in the world. the main reason for that is because i managed at europython to port pyjamas-desktop to the competitor to pywebkitgtk: python-xpdom. it uses XUL (mozilla). so, pyjamas developers can develop applications to run in web browsers (compiled to javascript) _or_ they can run them as desktop apps... .... no longer using webkit, but using mozilla technology instead. > the next step would be to post a new monolithic patch for review > addressing feedback in Comment #191 and Comment #194. ok. the comments are related to a (highly modified) patch which i could not get involved in, because of the removal of the event handling. so, *sigh* it's necessary to take two steps back in order to take one step forward, for which i apologise (both to you, and to adam - sorry, adam, but removing the event handling, i know why you did it, as it took me three days to update to the latest svn, last week, but i have to work from what i know and what i can prove works). so i'll endeavour to address the comments where they are relevant. one immediately that can be addressed: custom attributes. > > + if ($attribute->signature->extendedAttributes->{"Custom"} || > > + $attribute->signature->extendedAttributes->{"CustomGetter"} || > > + $attribute->signature->extendedAttributes->{"CustomSetter"}) { > > + return 1; > > + } > [Custom] and related attributes are only used for implementing JS specific > quirks and should not be needed for GObject bindings. the assertion that they are JS-relevant-only is not true, and you can test this by removing the "custom" test in the generator, and trying to add everything. i found this out myself by accidentally removing it, thanks to an error in the generator logic, whoops :) certain classes do not have corresponding IDL files. one such class is "Object". there is no IDL file for "Object", therefore no Gdom file gets auto-generated. but, that doesn't stop the auto-generator from trying to use a class "GdomObject", and from adding a header #include <gdom/GdomObject.h>" - which of course doesn't exist. there were a hell of a lot of these when i started in august - i decided "stuff it, i'm cutting these all out, and will deal with them later". so, the "custom" test is utilised to skip many of these issues, until the time is found to re-add them, one by one, or just try them all and then deal with any classes and errors that crop up. ... but _not_ right now. so - the custom-property-skipping stays, as a way to reduce the number of issues to be dealt with, as way to reduce the amount of auto-generated code, as a way to make this a more manageable project. many of the comments will be along these lines. i will make a best effort to address as many as possible, in one go, but i _strongly_ urge you to consider the burden of having to review such whopping great patches, which are so thoroughly detailed and cover at least five specialist technical areas all at once, again and again. i do have an updated patch ready, but at europython i found that the use of gtk dialog boxes for "alert" messages resulted in a total lock-up of pywebkitgtk, on some of the larger applications. if i find that this is a bug _without_ the #16401 patch (on some big JS-based apps), then i will proceed. also, one of the suggestions from alp, with which i thoroughly concur, is that this code should reeeally consider to be ... deactivated and require some special #ifdef or other switch (configure?), in order to be used. in that way, people won't try to go developing off into the distance with it until the various issues, which will be raised and dealt with after the patch is landed, are answered to everyone's satisfaction. i also strongly recommend that reviewers consider raising issues in specific small technical areas and as _separate_ bugreports (depending on this one) so that interested contributors who would like to see this move forward can tackle the specific area with a single small patch. for example, one contributor might want to deal with the AddRef / unref issue as a single patch. [to do that right now has already proven to be too challenging and time-consuming] ... of course, this is all only advice. you have no reason to listen to my advice, and are free to ignore it and to continue to be subjected to considerable stress in dealing with this work - that is entirely your right :) l. p.s. btw, david, and any of the reviewers: i have a thought for you to consider, if you have time: perhaps you might like to consider downloading the branch i'm maintaining at github.com/lkcl/webkit/16401.master, and also the pywebkitgtk patch #13 at code.google.com/p/pywebkitgtk, and also the http://pyjs.org project from subversion, and try out the pyjamas examples. it will give you a little bit more confidence that this is something that a) works b) is very cool. c) you'll have some way to actually test and get to grips with the 16401 patch. at the moment, i'm fully aware that 16401 is a... nebulous sort-of... non-graspable entity which you just don't have a handle on, and as such, it's difficult to appreciate the direction that this is going. constant reviewing of thousand-line patches can't be fun, given the complexities involved, and i feel that if you knew exactly what can and is being achieved with this patch you would feel much more comfortable with it.

Luke Kenneth Casson Leighton

Comment 216 2009-07-12 12:26:13 PDT

(In reply to comment #191) > (From update of attachment 29670 [details]) > > # Script for creating hash tables > > @@ -110,7 +111,8 @@ javascriptcore_cppflags += \ > > -I$(srcdir)/JavaScriptCore/ForwardingHeaders \ > > -I$(srcdir)/JavaScriptCore/parser \ > > -I$(srcdir)/JavaScriptCore/wtf \ > > - -I$(top_builddir)/DerivedSources > > + -I$(top_builddir)/DerivedSources \ > > + -I$(srcdir)/WebCore/bindings/webkit > > This and other changes to the include search path are a little bit of a concern > due to the layering violations they imply. JavaScriptCore should not depend on > headers in WebCore. WebCore should not depend on headers from WebKit. no, it should not, i absolutely agree. however, i tried very hard to make builds work without adding these in, and got exasperated enough to give up trying and just moved forward. core to the issue is that webkitwebframe.h now absolutely requires GdomDOMDocument, GdomNode, GdomXMLHttpRequest, GdomEventListener and a few others, and obviously their dependencies. so that's a _massive_ influx of extra header files, all of which are auto-generated and go into DerivedSources. so... exactly how should those derived sources, on which WebKitWebFrame is now dependent, get into the build, on which libwebkit now depends, and on which GtkLauncher etc. now also depend? it's a tricky one, and i look forward to this one being resolved _after_ the patch is landed. > > +webcoregtk_sources += \ > > + WebCore/bindings/gobject/webkitbinding.cpp \ > > + WebCore/bindings/gobject/webkitbinding.h \ > > + WebCore/bindings/gobject/WebKitDOMObject.cpp \ > > + WebCore/bindings/gobject/WebKitDOMObject.h \ > > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp \ > > + WebCore/bindings/gobject/webkithtmlelementwrapperfactory.h > > + > > It looks like some of these files do not follow the naming convention. This > should be addressed. they follow the naming conventions in the patch that i will submit after i have replied to #191 and #194. > > Index: WebCore/bindings/gobject/WebKitDOMObject.cpp > > =================================================================== > > --- WebCore/bindings/gobject/WebKitDOMObject.cpp (revision 0) > > +++ WebCore/bindings/gobject/WebKitDOMObject.cpp (revision 0) > > @@ -0,0 +1,28 @@ > > +/* > > + * Copyright (C) 2008 Luke Kenneth Casson Leighton <lkcl@lkcl.net> > > + * Copyright (C) 2008 Martin Soto <soto@freedesktop.org> > > + * Copyright (C) 2008 Alp Toker <alp@atoker.com> > > + * Copyright (C) 2008 Apple Inc. All Rights Reserved. > > + */ > > This file needs a license header. done. > > > +#include <glib-object.h> > > + > > +#include "config.h" > > +#include "webkitbinding.h" > > +#include "WebKitDOMObject.h" > > These includes should follow the order in the style guidelines (config.h, > WebKitDOMObject.cpp, blank line, remaining includes in sorted order). done. > > > =================================================================== > > --- WebCore/bindings/gobject/WebKitDOMObject.h (revision 0) > > +++ WebCore/bindings/gobject/WebKitDOMObject.h (revision 0) > > @@ -0,0 +1,56 @@ > > +/* > > + * Copyright (C) 2008 Luke Kenneth Casson Leighton <lkcl@lkcl.net> > > + * Copyright (C) 2008 Martin Soto <soto@freedesktop.org> > > + * Copyright (C) 2008 Alp Toker <alp@atoker.com> > > + * Copyright (C) 2008 Apple Inc. All Rights Reserved. > > + * > > + * This library is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU Library General Public > > + * License as published by the Free Software Foundation; either > > + * version 2 of the License, or (at your option) any later version. > > + * > > + * This library is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > + * Library General Public License for more details. > > + * > > + * You should have received a copy of the GNU Library General Public License > > + * along with this library; see the file COPYING.LIB. If not, write to > > + * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, > > + * Boston, MA 02110-1301, USA. > > + */ > > + > > + > > +#ifndef WebKitDOMObject_h > > +#define WebKitDOMObject_h > > + > > +#include "glib-object.h" > > If this header is included here, why is it also included in > WebKitDOMObject.cpp? Why does one place use "" while the other uses <>? i have nooo idea. probably because adam fixed one but not the other. > > +#include "webkit/webkitdomdefines.h" > > +#include <webkit/webkitdefines.h> > > Why does one of these includes use "" and the other <>? hmm, that doesn't look right.... hmmm, it's also... out-of-date. > > +struct _WebKitDOMObject { > > + GObject parent_instance; > > + > > + void *coreObject; > > +}; > > + > > +struct _WebKitDOMObjectClass { > > + GObjectClass parent_class; > > +}; > > + > > Some consistency on the naming style on these member variables would be nice. yes, it would... *sigh* these are partly-autogenerated i.e. from an early revision of the autogenerator i copied an auto-generated file and created GdomDOMObject.cpp from it. so... *hand-waving*... there is a convention of sorts - from the bindings and also from glib/gobject coding.... conclusion: not going to worry about this one right now. > > > > Index: WebCore/bindings/gobject/gstringconvert.h > > This file name doesn't fit our naming conventions. yep adam renamed it. it'll be GStringConvert.h > > =================================================================== > > --- WebCore/bindings/gobject/gstringconvert.h (revision 0) > > +++ WebCore/bindings/gobject/gstringconvert.h (revision 0) > > @@ -0,0 +1,37 @@ > > +/* > > + * Copyright (C) 2008 Luke Kenneth Casson Leighton <lkcl@lkcl.net> > > + * > > + * This library is free software; you can redistribute it and/or > > + * modify it under the terms of the GNU Library General Public > > + * License as published by the Free Software Foundation; either > > + * version 2 of the License, or (at your option) any later version. > > + * > > + * This library is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > > + * Library General Public License for more details. > > + * > > + * You should have received a copy of the GNU Library General Public License > > + * along with this library; see the file COPYING.LIB. If not, write to > > + * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, > > + * Boston, MA 02110-1301, USA. > > + */ > > + > > + > > +#ifndef GSTRING_CONVERT_H > > +#define GSTRING_CONVERT_H > > + > > +/* convenience functions for converting various webkit string types into a utf8 glib string */ > > WebKit. > > > +#include "AtomicString.h" > > +#include "CString.h" > > +#include "KURL.h" > > +#include "PlatformString.h" > > +#include "unicode/ustring.h" > > Why is the unicode/ustring.h include necessary here? it was added in a series of random attempts to get these string conversion routines to work. i believe that one of these gdom_gstring_converts works _because_ unicode/ustring.h is there, and there is an implicit c++ type conversion going on. > > +inline gchar * gdom_gstring_convert(WebCore::String const& s) { return g_strdup(s.utf8().data()); } > > +inline gchar * gdom_gstring_convert(WebCore::KURL const& s) { return g_strdup(s.string().utf8().data()); } > > +inline gchar * gdom_gstring_convert(const JSC::UString & s) { return g_strdup(s.UTF8String().c_str()); } > > +inline gchar * gdom_gstring_convert(WebCore::AtomicString const&s) { return g_strdup(s.string().utf8().data()); } > > This doesn't follow our coding style. The spacing around operators is > inconsistent, well spotted. > and the function names are using lower case with underscores. adam changed that. the patch i will resubmit has GdomGstringConvert. > > Index: WebCore/bindings/gobject/webkitbinding.cpp > > =================================================================== > > --- WebCore/bindings/gobject/webkitbinding.cpp (revision 0) > > +++ WebCore/bindings/gobject/webkitbinding.cpp (revision 0) > > @@ -0,0 +1,367 @@ > > The file name doesn't fit our convention, [adam again] does in the patch to be submitted. > and the include order in this file is > a bit whacky. It should be updated to follow the style guidelines, with the > duplicate headers removed. It may make sense to keep the generated headers in > a separate block, but the others should follow the style. added an explanation. not looking forward to shuffling 100 #includes. /* yes these are out-of-order, but they are grouped by * purpose. the #includes needed for toGDOM(Document*) * got added, and the ones for toGDOM(CSSRule*) got added * separately, and then some are conditional based on * compile-time options, and yet more will be added * e.g. for SVG Canvas. */ > > > +namespace WebKit { > > This seems a bit out of place inside WebCore, but perhaps it is intentional. yes, it is. it allows the toGDOM functions to be referred to as WebKit::toGDOM when they are used. > > +#include <wtf/Noncopyable.h> > > + > > +#include "CanvasPixelArray.h" > > +#include "CSSRule.h" > > +#include "CSSValue.h" > > +#include "Document.h" > > +#include "DOMWindow.h" > > +#include "Element.h" > > +#include "HTMLCollection.h" > > +#include "Node.h" > > +#include "StyleSheet.h" > > +#include "Text.h" > > Similar comment about includes here. looks out-of-date. GDOMBinding.cpp doesn't have wtf/Noncopyable.h > > + > > +namespace WebCore { > > + > > + class AtomicString; > > + class Document; > > + class Event; > > + class Frame; > > + class KURL; > > + class Node; > > + class String; > > Given some of the files that are included above, many of these forward > declarations are redundant. i'm not seeing those in GDOMBinding.cpp so that must have been adam, so this is now out-of-date. > > Index: WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp > > =================================================================== > > --- WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp (revision 0) > > +++ WebCore/bindings/gobject/webkithtmlelementwrapperfactory.cpp (revision 0) > > Is there some way we can autogenerate this file? It seems like it is almost > entirely boilerplate. yes. but not right now. it was copied from the auto-generated JSHTMLElementWrapperFactory.cpp and then i removed all references to exec*. perl not being my favourite language i couldn't face doing yet another adaptation of yet another perl script. so - one for a separate patch, after this patch has been landed. > > + > > +#include "glib-object.h" > > +#include <wtf/Forward.h> > > +#include "HTMLElement.h" > > + > > +namespace WebCore { > > + class HTMLElement; > > +} > > Including HTMLElement.h then forward-declaring HTMLElement is a bit redundant. nooot going to worry about it. > > Index: WebCore/bindings/scripts/CodeGeneratorGObject.pm > > =================================================================== > > --- WebCore/bindings/scripts/CodeGeneratorGObject.pm (revision 0) > > +++ WebCore/bindings/scripts/CodeGeneratorGObject.pm (revision 0) > > [ I'm skipping this file for now in hopes that I'll be able to convince Sam to > look at it. ] he he > > Index: WebCore/bindings/scripts/gobject-generate.pl > > =================================================================== > > --- WebCore/bindings/scripts/gobject-generate.pl (revision 0) > > +++ WebCore/bindings/scripts/gobject-generate.pl (revision 0) > > It may make more sense for this to be named in the same order as the other > "generate" script in that directory. [adam again]. keeping it as CodeGeneratorGObject.pl > > > Index: WebKitTools/GNUmakefile.am > > =================================================================== > > --- WebKitTools/GNUmakefile.am (revision 42662) > > +++ WebKitTools/GNUmakefile.am (working copy) > > @@ -4,8 +4,10 @@ noinst_PROGRAMS += \ > > > > # GtkLauncher > > Programs_GtkLauncher_CPPFLAGS = \ > > + -I$(srcdir)/WebCore/bindings \ > > -I$(srcdir)/WebKit/gtk \ > > -I$(top_builddir)/WebKit/gtk \ > > + -I$(srcdir)/WebKit/gtk/webkit \ > > $(global_cppflags) \ > > $(javascriptcore_cppflags) > > > > @@ -29,8 +31,10 @@ Programs_GtkLauncher_LDADD = \ > > dumprendertree_cppflags := \ > > -I$(srcdir)/WebKitTools/DumpRenderTree \ > > -I$(srcdir)/WebKitTools/DumpRenderTree/gtk \ > > + -I$(srcdir)/WebCore/bindings \ > > -I$(srcdir)/WebKit/gtk \ > > -I$(top_builddir)/WebKit/gtk \ > > + -I$(srcdir)/WebKit/gtk/webkit \ > > $(global_cppflags) \ > > $(javascriptcore_cppflags) > > > > DumpRenderTree should only be using API. It should not have any dependencies > on WebCore. yep. i know. see first reply, again. tried building without, and it just doesn't happen. resolving it is definitely a post-patch separate self-contained task.

Luke Kenneth Casson Leighton

Comment 217 2009-07-12 12:57:55 PDT

(In reply to comment #194) > (From update of attachment 29670 [details]) > I concur with Mark's review, this is not ready to be landed. I have gone > through the CodeGenerator and picked out a bunch of issues that really stick > out, but in general, I can't really review this as is. I believe the best way > forward is for you to pick one file (say Node.idl) and get code generation > working for it or a subset of it. that was what i was originally asked to do, back in .... mmmm... september. it was already too late, by then, and it's definitely too late now. adam's reply _also_ says "no". the time for "one file" (Node.idl) was approximately 24 hours after i started, in early august. but even then, as i looked at the dependencies it became abundandly clear that just one file wasn't going to cut it. so - we're well beyond that now. going "backwards" isn't going to happen. i realise however that you do need to review this, in some way. and, given that it's too big to review all at once, you _do_ need to have some level of confidence that it actually works - and get a handle on it. to do that, i recommend that you install pywebkitgtk (patched version) and perhaps even try running pyjamas-desktop. what you will then have is a code-base from which you can go "dang!" and can play around. also, i wrote a small (well, quite sophisticated) adapted version of GtkLauncher: http://lkcl.net/webkit/main.c which you can also play with simply by replacing the existing GtkLauncher's main.c > The stripped down version of the code > generator that can generate this one file will be a great jumping off point. I > know this seems like a step backwards, but the current state of the patch is > really not reviewable as is due to a lack of clarity in the code. The single > patch is trying to do too many things at once. it's _successfully_ doing many things at once, which you can demonstrate to yourself by installing pywebkitgtk and pyjamas-desktop. it's not my fault that this code hasn't been written at the same time as the other code-generators (which have copyright timestamps dating back to 2006). so - forward it is. > Here are some comments: > > > + if ($attribute->signature->extendedAttributes->{"Custom"} || > > + $attribute->signature->extendedAttributes->{"CustomGetter"} || > > + $attribute->signature->extendedAttributes->{"CustomSetter"}) { > > + return 1; > > + } > > [Custom] and related attributes are only used for implementing JS specific > quirks and should not be needed for GObject bindings. should not, but have been. detailed reply here: https://bugs.webkit.org/show_bug.cgi?id=16401#c215 short answer: they stay until each of the custom attributes can be reviewed on a case-by-case basis. > > + if ($prop_type eq "stylesheets::MediaList" or > > + $prop_type eq "CSSStyleDeclaration" or > > + $prop_type eq "CSSVariablesDeclaration" or > > + $prop_type eq "EventListener" or > > + $prop_type =~ /Constructor$/ or > > Constructors are a JS only idiom. i'm yet to be completely convinced, but am slowly coming round to it, that constructors should not be needed [in glib/gobject bindings]. some of the DOM objects are _completely_ inaccessible. XPathValidator is totally isolated and cannot be accessed, but mark kindly pointed out a couple of weeks ago that there is a Document-based access to the same functionality. so that one's sorted. however, TextDocument and XMLDocument are still utterly isolated. ... and yes, we have a pyjamas-desktop example which is still broken because we can't create an XML Document, because there's no function to access it. also, because a TextDocument cannot be created, XMLHTTPRequest has had to have its "open" function take a string parameter, and this alone warrants the #define to create a separate IDL #ifdef for Gobject bindings. so there is a lot left unanswered, and until it's answered for, i'm reluctant to go ripping out references to "constructors" until such time as it has been proven to my satisfaction that they are not needed. at all. > > + > > +sub UsesManualToJSImplementation { > > ??? How is this related to GObject support? not being funny or anything, but the answer is: don't know, and don't care. much of this code was developed on a evolutionary-style rapid development cycle that you will have difficulty believing in. for eight weeks solid, i was making approximately 150 to 300 modifications to CodeGeneratorGObject.pl and other source files _per day_, with over 250 simultaneous vi editor sessions open. this development style, of "trusting" what i could cut and paste from dozens of different sources, seems to have worked (as you can see from pyjamas-desktop). so - much of the code is, and will remain, "unexplained", like genetic code. the summary of all that is, as i said: i don't know, and you shouldn't care. if you do care, try taking it out, and see what happens. that's what i did, and i'm through with doing that [cycle of development], unless someone can show me a damn good justifiable reason for doing so. > > + my $type = shift; > > + > > + # skipped out CanvasPixelArray - see JSCanvasPixelArrayCustom.cpp for why. > > + return 1 if $type eq "Node" or $type eq "Document" or $type eq "HTMLCollection" or > > + $type eq "SVGPathSeg" or $type eq "StyleSheet" or $type eq "CSSRule" or $type eq "CSSValue" or > > + $type eq "Event" or $type eq "Element" or $type eq "Text"; > > + return 0; > > +} > > + > > +sub WritePrivateHeader { > > + my $object = shift; > > + my $class = shift; > > + > > + my $interfaceName = $class->name; > > + my $className = GetClassName($interfaceName); > > + my $filename = "$outputDir/" . $className . "Private.h"; > > + my $guard = uc(decamelize($className)) . "_PRIVATE_H"; > > + my $parentClassName = GetParentClassName($class); > > + > > + my $hasLegacyParent = $class->extendedAttributes->{"LegacyParent"}; > > LegacyParent is a JS only idiom. see above. don't know don't care. it just works. it ain't broken. feel free to fix it [later]. > > + my $hasRealParent = @{$class->parents} > 0; > > + my $hasParent = $hasLegacyParent || $hasRealParent; > > + > > + open(PRIVHEADER, ">$filename") or die "Couldn't open file $filename for writing"; > > + > > + print PRIVHEADER split("\r", $licenceTemplate); > > + print PRIVHEADER "\n"; > > + > > + my $text = << "EOF"; > > +#ifndef $guard > > +#define $guard > > + > > +#include <glib-object.h> > > +#include <webkit/${parentClassName}.h> > > +#include "${interfaceName}.h" > > +EOF > > + > > + print PRIVHEADER $text; > > + > > + print PRIVHEADER map { "#include \"$_\"\n" } sort keys(%hdrPropIncludes); > > + print PRIVHEADER "\n" if keys(%hdrPropIncludes); > > + > > + $text = << "EOF"; > > +typedef struct _${className} ${className}; > > + > > +namespace WebKit { > > + ${className} * > > + wrap${interfaceName}(WebCore::${interfaceName} *coreObject); > > + > > + WebCore::${interfaceName} * > > + core(${className} *request); > > + > > +EOF > > + > > + print PRIVHEADER $text; > > + > > + if (${interfaceName} eq "DOMWindow" || (!$hasParent or $class->extendedAttributes->{"GenerateToJS"}) and > > + !UsesManualToJSImplementation($interfaceName)) { > > + $text = << "EOF"; > > What is this trying to do? that question really needed to be asked in september of 2008, some eight months ago, when i had a full working knowledge of this code in my head. if you want an answer now, you'll need to experiment (like i did). > > +sub Uniquify { > > + my $name = shift; > > + my $avoid = shift; > > + if ($name eq $avoid) { > > + $name = $name . "2"; > > + } > > Please explain this. i don't know what it is, and it's not in the patch that i'm going to submit after reading these comments. > > + if($attribute->signature->extendedAttributes->{"ConvertFromString"}) { > > This is a JS idiom. yes. i found that it got in the way, and i appear to have deleted it from the latest version. it wasn't until i started delving into pyjamas-desktop in a heavy-duty way that i found that some functions _require_ NULL etc. and that these things got in the way. so - out they went. seemed to work, too, which is good :) > > + # TODO: Add other conversion functions for different types. Current > > + # IDLs only list longs. > > + if($gtype eq "long") { > > + $convert_fn = ""; > > + $post_convert_fn = ".toInt()"; > > + } else { > > + die "Can't convert to type ${gtype}."; > > + } > > + } > > + > > > + if ($gtype eq "int") { > > + $txt_install_prop = << "EOF"; > > + G_MININT, /* min */ > > + G_MAXINT, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "boolean") { > > + $txt_install_prop = << "EOF"; > > + FALSE, /* default */ > > +EOF > > + } elsif ($gtype eq "float") { > > + $txt_install_prop = << "EOF"; > > + G_MINFLOAT, /* min */ > > + G_MAXFLOAT, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "double") { > > + $txt_install_prop = << "EOF"; > > + G_MINDOUBLE, /* min */ > > + G_MAXDOUBLE, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "uint64") { > > + $txt_install_prop = << "EOF"; > > + 0, /* min */ > > + G_MAXUINT64, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "ulong") { > > + $txt_install_prop = << "EOF"; > > + 0, /* min */ > > + G_MAXULONG, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "long") { > > + $txt_install_prop = << "EOF"; > > + G_MINLONG, /* min */ > > + G_MAXLONG, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "uint") { > > + $txt_install_prop = << "EOF"; > > + 0, /* min */ > > + G_MAXUINT, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "ushort") { > > + $txt_install_prop = << "EOF"; > > + 0, /* min */ > > + G_MAXUINT16, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "uchar") { > > + $txt_install_prop = << "EOF"; > > + G_MININT8, /* min */ > > + G_MAXINT8, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "char") { > > + $txt_install_prop = << "EOF"; > > + 0, /* min */ > > + G_MAXUINT8, /* max */ > > + 0, /* default */ > > +EOF > > + } elsif ($gtype eq "string") { > > + $txt_install_prop = << "EOF"; > > + "", /* default */ > > +EOF > > + } elsif ($gtype eq "object") { > > + $txt_install_prop = << "EOF"; > > + WEBKIT_TYPE_${propGType}, /* gobject type */ > > +EOF > > + } > > + push(@txt_install_props, $txt_install_prop); > > + $txt_install_prop = << "EOF"; > > + (GParamFlags)${gparamflag})); > > + > > +EOF > > This should probably be done in a more generic way using a hash. yes. that would be nice. it should go on the TODO list, for after when the patch has been landed. right now however, what's there works. so, many apologies sam - many of these questions are far far too late, and others raise some nice issues which will help improve the maintainability at a later date. and, unfortunately, some are out-of-date. overall, however, there isn't anything that you've raised which warrants any changes. they all fall into "too unsafe to consider doing; were made by adam and so are irrelevant now; too late to answer". the development process isn't "over", not by a long shot, but what's there can be proven, empirically and indirectly, to "work", and, given the level of complexity and the THREE levels of indirection between the code and its [current and only] test environment, pyjamas-desktop, fiddling with the code generator to do "tidyups" will prove to be a significantly bad / time-consuming idea.

Luke Kenneth Casson Leighton

Comment 218 2009-07-12 14:28:05 PDT

Created attachment 32633 [details] brings glib/gobject bindings up to svn r44473. okaay, this is the "2 steps backwards, 1 step forwards" patch which, as explained, cannot take into consideration adam's fantastic work because it was impossible for me to follow it. even _one_ feature removed (and the first that adam picked was event handling) meant that the test framework (pyjamas desktop) was totally cut off at the knees. dave agrees - https://bugs.webkit.org/show_bug.cgi?id=16401#c214 - that the way forward is to take this "as-is" and then to move forward from there. over what is likely to be a period of several months, retro-fix issues that have been raised and recorded will - should - be created. it would have been nice if people had listened to my advice on this months ago, but, not believing me, you had to find out for yourselves [by taking up adam's time as well as mine]. at least we're moving forward, now, rather than playing silly buggers. i'll be _more_ than happy to help review individual small dedicated controlled manageable single-purpose patches that anyone cares to contribute: perhaps by comparing the differences between what adam has done and what this patch provides it may make individuals' lives easier when it comes to updating this strategically critical area of functionality. there is a _lot_ still left to be done - but, butbutbut, what is here is _provably_ working. it would be very nice if it stayed that way, and that pyjamas-desktop, the only current project which utilised these bindings with near 100% code coverage, carried on working. still on the critical TODO list, after this patch is accepted (let alone any bug-fixes / coding-standards / review update work!) is: Enums, SVG 2D Canvas, and Exception handling. this latter is proving tiresome to not have, in pywebkitgtk (and pyjamas-desktop): several bugs could not be found in pyjamas-desktop until python-xpcom / XULRunner was added as an alternative back-end peer [to pywebkitgtk]. up until then, due to the lack of error reporting from runtime exceptions, style attributes and a few others just... silently vanished (fortunately with no useability impact, but that was down to luck). as requested, i've made review comments to https://bugs.webkit.org/show_bug.cgi?id=16401#c191 and https://bugs.webkit.org/show_bug.cgi?id=16401#c194 - the coding-standards issues i immediately fixed (as they're dead-easy) however there were issues raised that should have been raised eight months ago, when i had a complete map of the code and a handle on the 600+ auto-generated files in my head. i've answered them as best i can: now it's time to move on. one thing that can be seen from this patch: it includes LANGUAGE_GOBJECT as a #define. this is in for two separate reasons: 1) until someone can show me how to get a TextDocument object, in order to pass it to XMLHttpRequest.open(), for that reason and for that sole reason alone, LANGUAGE_GOBJECT is _absolutely_ required, in order to reactivate open(DOMString). otherwise, it's simply not possible to get XMLHttpRequest to work, and XMLHttpRequest working is a critical requirement of pyjamas-desktop [what's the point of having python bindings that are identical and a peer with the javascript ones if AJAX is bloody well missing???! :) ] 2) removal of LANGUAGE_GOBJECT was requested several months ago because it introduced features which are present in the de-facto Javascript standard (i.e. anyone coming from javascript would not be in for some unpleasant surprises) and it was stated that these features are not present in the W3C standard. after some extensive research, it was demonstrated that this wasn't quite true: the W3C standard makes specific mention that certain browser engines _do_ support the features. in fact, the research showed that by not having these features (i.e. by conforming strictly to the W3C standards), webkit would in fact be the _only_ major web engine that would not be on a par with its peers! even MSHTML has better support, because thanks to DCOM which has LP_VARIANT (which can take int, string, or in fact anything) and thus, unlike any of the other DOM implementations, the MS implementation of the DOM functions can support _both_ the W3C standard _and_ the de-facto javascript-led standard. regarding 2), i have put considerable thought to the matter and have some insights to share. from the perspective of the objective-c bindiings, strict W3C DOM standards compliance may make perfect sense. objective-c is a _compiler_. the auto-generated webkit objective-c header files are utilised at _compile_ time by the compiler to perform type-checking that can result in developers catching errors immediately. and, in objective-c, developers can take advantage of c++ classes that will be compiled, again at _compile_ time, into type-converters that will take strings as input, and convert to integers, and much much more. however - the glib/gobject bindings will - and are - be utilised by INTERPRETED languages. there is a WHOPPING great world of difference. there are two such (auto-generated) language bindings already (vala and python), and there will be more. vala - https://bugs.webkit.org/attachment.cgi?id=27558 python - http://code.google.com/p/pywebkitgtk/issues/detail?id=13 in the python case, the (currently sole and exclusive) project which is using pywebkitgtk with the DOM bindings is pyjamas - a python-to-javascript compiler. in other words, the only test case - the only really big significant (free software) test platform for the webkit glib bindings has a javascript-only cousin. that means that any applications written for pyjamas-desktop (which uses either pywebkitgtk or XULrunner python-xpcom) can also run as javascript, in all major web browsers. _that_ means that application developers may be developing exclusively in javascript, using the pyjamas python-to-javascript compiler. then, they encounter a requirement to have the application run as a stand-alone desktop app. then they download pywebkitgtk.... ... and they get a nasty big shock because the bloody underlying API is subtly different. without LANGUAGE_GOBJECT, all toString() functions would be missing; there would be no way to get the range of selected text out of input nodes; embed nodes would suddenly lose their width and height settings; XMLHttpRequest would be completely broken, and a few other nasty surprises. not one of these things is acceptable. the workarounds aren't particularly nice, either, and - again, the workarounds would be _great_ if these were COMPILED languages, with virtual base class function pointers etc. - but they're not: they're INTERPRETED languages, just like javascript. which reminds me of the other reason why many of the JS-isms should be enabled (such as getBoxObjectFor). again: in COMPILED languages, which are damn fast, calling functions like getBoxObjectFor via two or three levels of indirection makes absolutely no sense: just grab the attributes (width, height, top, left) individually and directly and write your own version of getBoxObjectFor which will, thanks to being a compiled language, be far far quicker. NOT so, in interpreted languages such as python. why? well, have you ever looked at python's Objects/abstractobject.c source code? it makes for interesting reading. and that's where all object access starts out. every single add, multiply, etc. goes through potential coercion checking. a single optimisation is made to check whether the two types are "int", and this is the _only_ case which is made faster: everything else goes through the "approx one hundred lines of c-code" route. just to do an add, or a multiply. so the very reasons for which the javascript-isms were created are just as equally valid for other dynamic languages as they are for javascript. overall then, for many many reasons, there is an overall compelling case to be made for sticking to the de-facto javascript standards over the W3C standards, for the glib/gobject bindings, and as equally a compelling case to be made for sticking to the W3C standards for the objective-C bindings. the two should not be confused, and developers using interpreted languages should not be put to incredible inconvenience (as well as the developers of the intermediate bindings) just for the sake of it. l.

Xan Lopez

Comment 219 2009-07-12 15:11:21 PDT

Speaking on behalf of the maintainers of the GTK+ port I'd like to reiterate what has been said in comments #194 and #195: - After many rounds of review it's obvious by now that this patch can't be reviewed as is, and that no one (neither core WebCore people nor the maintainers of the GTK+ port) is willing to land unreviewed code. - This patch should be redone from scratch, incrementally, and starting with a very small subset of the existing functionality. See comment #194 for a suggestion of how to start doing this. Anyone is free to try this approach, and we'll help as much as our time permits, but re-posting the huge monolithic patch won't get us anywhere. - This bug is approaching the point where its length makes it unmanageable, so please let's try to be concise in our comments and let's stick to what was agreed in the comments I have cited.

Luke Kenneth Casson Leighton

Comment 220 2009-07-13 03:14:31 PDT

(In reply to comment #154) > The patch breaks srcdir != builddir builds btw. It seems to delete a bunch of > -I$(top_builddir)... for no apparent reason and replaces other $(builddir) with > $(srcdir) variants. I just fixed it by reverting those, but for some reason > also had to go to WebKitTools/GNUmakefile.am and add -I$(top_builddir)... flags > to the tools flags. yes, that sounds about right: now you know why i did it, originally. the original work and the newly-updated patch both work with srcdir != builddir. i use it all the time to do debian builds using dpkg-buildpackage, and that uses ./build/....

Luke Kenneth Casson Leighton

Comment 221 2009-07-13 03:56:10 PDT

(In reply to comment #219) > Speaking on behalf of the maintainers of the GTK+ port I'd like to reiterate > what has been said in comments #194 and #195: > > - After many rounds of review it's obvious by now that this patch can't be > reviewed as is, and that no one (neither core WebCore people nor the > maintainers of the GTK+ port) is willing to land unreviewed code. hiya xan, dave has kindly agreed to exactly that. the patch has been reviewed dozens of times already; many of the issues have been addressed, whilst, as i initially recommended way back in ... september, i will be happy to help contribute, and to help others contribute, smaller manageable easily reviewable single-purpose patches that will of course always go through the standard review process. > - This patch should be redone from scratch, should? probably, yes. count me out, though - i've done it once, and i know what a bitch of a job it is. > incrementally, and starting with a > very small subset of the existing functionality. two people tried that. they're both people who went to a lot of trouble to try to work with the apple review process, and they both, after finding it to be too difficult, went "no. we're not doing that". so you should give serious consideration to listening to the wisdom learned and relayed from their experience, which is "no - bad idea". once is enough. > See comment #194 for a > suggestion of how to start doing this. Anyone is free to try this approach, the flaw is simple: given that this patch already exists (and can be proven at a high-level using pywebkitgtk and pyjamas-desktop with the pywebkitgtk back-end enabled to actually work ) as i mentioned to dave, i seriously doubt whether you will find anyone willing to try. especially when they look through these comments and find such a stinging amount of hostility in the review process, towards contributions in this highly-technical area. you have to remember that the areas of expertise required include: * c * c++ * working knowledge of objective-c/c++ * specialist working knowledge of the internals of WebKit / WebCore * gtk * detailed and full working knowledge of glib/gobject * a dynamic language (e.g. python, vala) * knowledge of code-bindings-generation for that language (e.g. codegen.py) * perl * autoconf. * the very latest GNU makeisms * experience in working at 2nd and 3rd hand in code generation * a very good memory * knowledge of javascript * knowledge of the W3C standards and even then, that's still not enough - you have to put that all together, for several weeks, so that you can stay on top of the whole lot. why do you think i worked and worked and worked on this and did not stop for eight weeks at 11 hour days? > and > we'll help as much as our time permits, but re-posting the huge monolithic > patch won't get us anywhere. fortunately, it has got somewhere - see #214. > - This bug is approaching the point where its length makes it unmanageable, yes - that's why i suggested the "land it first, then fix issues later" approach. initially that idea was met with completely inappropriate derision and scorn, and with "what makes _you_ so special, <insert derogatory swearword here>?" type direspectful and socially unhelpful comments, for which i haven't received an apology. eight months, 120 comments and several wasted man-months later, the wisdom of my initial suggestion is being understood, and has been given due consideration. it's just sad that it's taken so long, and that otherwise good engineers felt the need to pour derision on this work, making the process of acceptance of it that much more painful - for themselves. a real pity. anyway. if you stick to the plan, you have my help. eight months late, i now don't have a _complete_ map of this code in my head, and only have enthusiasm for going forward, not backwards. that having been said, i'm happy to lead the development of these bindings and see them through. once this patch is landed, as agreed, i will help create a list of individual bugreports, splitting out individual review comments and cross-referencing them. (that itself is the kind of easy task which anyone can help contribute to, btw) things like: * rename Gdom to Webkit and GDOM to WEBKIT - this is an easy task that will be a tiny self-contained patch * fix the ref() unref() RefPtr<> issue - this is a specialist task that is again easy for someone who understands WebKit internals * write some perl to auto-generate the HTMLWrapperFactory code. this is an easy task that will be a tiny self-contained patch * fix the #includes of DerivedSources/gdom that have had to be added to several places, making sure that $srcdir != $builddir works. this is an easy task for anyone with specialist knowledge of gnu autoconf and gnu makeisms that will be a tiny self-contained patch. * fix the use of Custom and CustomGetter and CustomSetter. this is a faairly easy task that involves commenting out a few lines of the CodeGeneratorGObject.pm and seeing what breaks. again, it will be a tiny self-contained patch so that's five small pieces of work that are self-contained and can all be done at the same time by different people, and will, post-patch-acceptance, result in the review process for #16401 being fulfilled satisfactorily. there are plenty more like that, and i look forward to helping you and others identify them and i look forward to helping to review contributions to fix them. we have months of work to go on this as it is: this _working_ i repeat PROVABLY WORKING first version is just the beginning. l.

Luke Kenneth Casson Leighton

Comment 222 2009-07-13 03:58:25 PDT

(In reply to comment #221) > things like: * reintroduce adam's excellent work, one self-contained patch at a time.

David Kilzer (:ddkilzer)

Comment 223 2009-07-13 17:17:23 PDT

(In reply to comment #218) > Created an attachment (id=32633) [details] > brings glib/gobject bindings up to svn r44473. > [...] > > dave agrees - https://bugs.webkit.org/show_bug.cgi?id=16401#c214 - that the way > forward is to take this "as-is" and then to move forward from there. over what > is likely to be a period of several months, retro-fix issues that have been > raised and recorded will - should - be created. it would have been nice if > people had listened to my advice on this months ago, but, not believing me, you > had to find out for yourselves [by taking up adam's time as well as mine]. at > least we're moving forward, now, rather than playing silly buggers. Please forgive me, I thought that Adam's patch contained the entire body of work when I wrote Comment #214. I withdraw my statement that it would be okay to land the full patch in one piece.

Gour

Comment 224 2009-07-13 23:23:33 PDT

(In reply to comment #223) > Please forgive me, I thought that Adam's patch contained the entire body of > work when I wrote Comment #214. I withdraw my statement that it would be okay > to land the full patch in one piece. Huh, this is going to nowhere-land... Luke, run away from here and focus on xulrunner. ;) Sincerely, Gour

Gour

Comment 225 2009-07-13 23:25:56 PDT

(In reply to comment #224) > Luke, run away from here and focus on xulrunner. ;) > > > Sincerely, > Gour Leaving this one...

Luke Kenneth Casson Leighton

Comment 226 2009-07-14 02:05:17 PDT

Luke Kenneth Casson Leighton

Comment 227 2009-07-14 02:08:38 PDT

(In reply to comment #224) > (In reply to comment #223) > > > Please forgive me, I thought that Adam's patch contained the entire body of > > work when I wrote Comment #214. I withdraw my statement that it would be okay > > to land the full patch in one piece. > > Huh, this is going to nowhere-land... > > Luke, run away from here and focus on xulrunner. ;) no need, gour - xulrunner support in pyjamas-desktop is done! it took under 3 days, i'm just tying up loose ends now. my next plan is to move on to MSHTML. that will make webkit a third rate citizen as far as free software community support from apple is concerned.

Luke Kenneth Casson Leighton

Comment 228 2009-07-14 02:28:19 PDT

(In reply to comment #223) > (In reply to comment #218) > > Created an attachment (id=32633) [details] [details] > > brings glib/gobject bindings up to svn r44473. > > [...] > > > > dave agrees - https://bugs.webkit.org/show_bug.cgi?id=16401#c214 - that the way > > forward is to take this "as-is" and then to move forward from there. over what > > is likely to be a period of several months, retro-fix issues that have been > > raised and recorded will - should - be created. it would have been nice if > > people had listened to my advice on this months ago, but, not believing me, you > > had to find out for yourselves [by taking up adam's time as well as mine]. at > > least we're moving forward, now, rather than playing silly buggers. > > Please forgive me, I thought that Adam's patch contained the entire body of > work when I wrote Comment #214. I withdraw my statement that it would be okay > to land the full patch in one piece. so, david, just to reiterate the sequence of events, so that things can be fully understood: * patch began, with a goal to making python a full and complete peer of its javascript bindings and also of the competition such as python-xpcom and MSHTML * patch submitted with the expectation of enthusiasm and support of apple and free software community. * patch demanded to be "cut down" which went down like a lead balloon. * patch completed to meet initial goals and milestones. first release made on sourceforge. * patch worked on by yorba to meet some of apple reviewers' demands [as well as very sensible requests]. * too much removed, to meet demands, to make it possible for patch to be used and tested [under pyjamas-desktop] * agreement reached to move forward [with misunderstanding] * "2 steps backwards, 1 step forwards" patch created, along with a roadmap to move forward in small incremental steps. * misunderstanding highlighted. so, as you can see, the root cause of the misunderstanding is the demands made by apple reviewers to remove critical LANGUAGE_GOBJECT functionality. amongst other things. if those demands had not been made, adam's excellent work would contain the necessary features required for me to be able to continue from where his company told him to leave this alone. well - it wouldn't have contained event handling, but being only that one thing missing i could have added that back in. so, you only have yourselves to blame, for misdirecting, misguiding and abusing the resources and time of those volunteers and members of the free software community willing to contribute. that the level of expertise required to contribute is so high leaves you now with a serious problem. one which a few apologies and some inclusive discussions instead of statements including sentences "that's not the vision for webkit language bindings that apple has" would go a long way towards repairing the damage that apple has done to its reputation.

Gustavo Noronha (kov)

Comment 229 2009-07-14 14:47:35 PDT

(In reply to comment #227) > that will make webkit a third rate citizen as far as free software > community support from apple is concerned. 1. This has nothing to do with apple; we are the webkit project, not apple. 2. I am as Free Software community as you are, and know that Epiphany, Midori, Empathy, Devhelp are very happily using WebKitGTK+, despite whatever you think. 3. You, as always, see your project as the most important thing on earth, and probably as more representative of the Free Software community than any of the other projects. I'm sorry to tell you it is not.

Luke Kenneth Casson Leighton

Comment 230 2009-07-15 03:10:23 PDT

(In reply to comment #229) > (In reply to comment #227) > > that will make webkit a third rate citizen as far as free software > > community support from apple is concerned. > > 1. This has nothing to do with apple; we are the webkit project, not apple. ahh, that's good to hear. given that the key reviewers with the most objections and the least willingness to engage in technical discussions that counter those objections were apple employees, i was under the mistaken impression that apple controlled webkit. if the webkit project is willing to engage and discuss the researched material (which, i have to point out, has been requested ten times now) shown from here onwards (#121 - #127): https://bugs.webkit.org/show_bug.cgi?id=16401#c121 if the webkit project is willing to review those responses, which were made in response to review comments, we can move forward! which is brilliant. i'm encouraged that you are willing to do that. > 2. I am as Free Software community as you are, and know that Epiphany, Midori, > Empathy, Devhelp are very happily using WebKitGTK+, despite whatever you think. ah - thank you for saying this, because you highlight a mistake that i made in what i said, and that is always appreciated. i meant to say, "as far as declarative-style expansion of webkit to other programming languages is concerned, through language bindings..." which is of course completely different. so, i apologise for taking up your time with a mistake on my part, i had assumed that it would be clear from the context, as this patch provides language bindings and thus opens up webkit in an exciting new way for free software. now - specifically regarding the projects that you mention, i _would_ go and look through them to see if there are any language bindings to DOM, but, given that this is the only place where that is done, i can say with a high degree of confidence that they don't make use of this patch. so, epiphany, midori, empathy and devhelp are quite happily using webkitgtk+ but they are not using python, vala or any other dynamic language (other than javascript) to manipulate the DOM model in any way, shape or form. so in that regard, your point is moot, and i apologise once again for not making things clear enough such that you felt it necessary to defend these projects. if this patch was affecting or contributing to the _core_ functionality, for example if it was a performance improvement or a port of webkitgtk+ to an esoteric embedded system or something, then you would be absolutely correct in defending those projects. but, this is a _massive_ enhancement that has no bearing on those projects at all, so it is a moot point. > 3. You, as always, see your project as the most important thing on earth, ahh, there, now, you're making assumptions, which is always a bad idea, and as an experienced free software developer, i am surprised that you would make such assumptions. surely you did not mean to make such an assumption, but i cannot guess what you meant to say. perhaps you might like to make a correction to your statement which will help the technical progression of this work? otherwise, your statement might be misconstrued as ... gosh, how to put this without causing offense... "gesturing" is perhaps the most diplomatic word. i trust that you will in no way take offense by me merely pointing out how your assumption might be viewed, and that you will immediately take the time to correct any assumptions or mistaken impressions that _i_ might have. in this way, it will be possible for us to move forward on a sound footing, with no assumptions made that could aggravate the development of this work, such that we can move forward on the progression of free software and of this particular part of it. > and > probably as more representative of the Free Software community than any of the > other projects. I'm sorry to tell you it is not. i'm sorry, gustavo, but i am very confused by the purpose and the intent behind these statements. i cannot see any technical or strategic merit behind them which helps contribute to webkit or to the progression of this patch. perhaps you might like to send a message which indicates to future readers that you apologise for making assumptions about me, apologise for taking up peoples' time and asking the comment to be disregarded from the discussions. as a member of the webkit team and as an experienced free software developer, i look forward to hearing further input from you which contributes to the technical and strategic progress of this work.

Christian Dywan

Comment 231 2009-07-15 04:58:48 PDT

> > 2. I am as Free Software community as you are, and know that Epiphany, Midori, > > Empathy, Devhelp are very happily using WebKitGTK+, despite whatever you think. > [...] > so, epiphany, midori, empathy and devhelp are quite happily using > webkitgtk+ but they are not using python, vala or any other dynamic > language (other than javascript) to manipulate the DOM model in any way, > shape or form. You misunderstand. DOM binding in the sense of the motivation of this bug report is about C language bindings. Hence the mentioned projects are unable to manipulate the DOM other than via javascript in exactly the same way as any python or vala application is. > > 3. You, as always, see your project as the most important thing on earth, > > ahh, there, now, you're making assumptions, which is always a bad idea, > and as an experienced free software developer, i am surprised that you > would make such assumptions. > [...] Please quit commenting in this overly verbose and disruptive fashion, as Xan requested, and as was requested before. You are free to open up a personal website and post rants there, but keep it short in bugzilla. Thanks.

Luke Kenneth Casson Leighton

Comment 232 2009-07-15 09:47:58 PDT

(In reply to comment #231) > > so, epiphany, midori, empathy and devhelp are quite happily using > > webkitgtk+ but they are not using python, vala or any other dynamic > > language (other than javascript) to manipulate the DOM model in any way, > > shape or form. > > You misunderstand. DOM binding in the sense of the motivation of this bug > report is about C language bindings. christian, you are funny > Hence the mentioned projects are unable to > manipulate the DOM other than via javascript in exactly the same way as any > python or vala application is. i apologise, i > > > 3. You, as always, see your project as the most important thing on earth, > > > > ahh, there, now, you're making assumptions, which is always a bad idea, > > and as an experienced free software developer, i am surprised that you > > would make such assumptions. > > [...] > > Please quit commenting in this overly verbose and disruptive fashion, christian, with respect, i invite you to consider some things. is it okay if i point out people's assumptions about me, which could be viewed as either misguided, misinformed or as personal attack? is it okay if i use this bugtracker to give people the benefit of the doubt and an opportunity to correct any mistaken impressions? i am endeavouring to get this discussion onto technical issues, and i am keenly aware that there seems to be a high percentage of people willing to talk rather than act in a way that moves this technical issue forward. my technical contributions and technical questions remain unanswered. how should i react? in good faith, i ask you genuinely to advise me how i should react to that. > as Xan > requested, and as was requested before. You are free to open up a personal > website and post rants there, but keep it short in bugzilla. Thanks. i'm sorry that you feel that it is okay for people to use this bugtracker to make assumptions and non-technical contributions, but that it is not okay for me to point that out. i also apologise for having to take so much of everyone's time apologising and for taking up peoples' time having to deal with incorrect assumptions and more. i welcome advice from people on ways to move this technical issue forward, as well as contributions to the technical issues at hand. so. xan. christian. gustavo. mark. dave. your agreement is sought to keep discussions here related to a minimum - of technical discussions and issues, with _mutual_ respect and due consideration for all contributions. i trust that this meets with your approval and your agreement.

Luke Kenneth Casson Leighton

Comment 233 2009-07-15 10:06:59 PDT

(In reply to comment #232) > > You misunderstand. DOM binding in the sense of the motivation of this bug > > report is about C language bindings. > > christian, you are funny > > > Hence the mentioned projects are unable to > > manipulate the DOM other than via javascript in exactly the same way as any > > python or vala application is. > > i apologise, i achh, darnit, please disregard this sentence and the one above: as you can see from the incomplete sentence i hit send too soon. i apologise for taking up peoples' time with incomplete replies, _especially_ ones responding to non-technical discussions.

Luke Kenneth Casson Leighton

Comment 234 2009-07-15 12:28:36 PDT

(In reply to comment #215) > > After re-reviewing some of the comments, I think my comment that the patch > > "must be broken up in to smaller pieces" may be worded too strongly. In > > Comment #76, breaking up the patch is suggested as a best practice for new > > contributors and will lead to quicker turnaround (reviews) on posted patches, > > but it's not a strict requirement. > > ah, whew, that's a relief. > > > However, since you're unwilling to break it up > > it's more than that, it's that by doing so i cannot make any guarantees that > the individual portions are either correct or actually do anything. it was > only by having pretty much absolutely everything that i could get > pyjamas-desktop to work, and thus run the high-level tests (pyjamas examples, > pyjamas unit tests etc.) > > > (and since willing to be patient), > > got all the time in the world. the main reason for that is because i managed > at europython to port pyjamas-desktop to the competitor to pywebkitgtk: > python-xpdom. it uses XUL (mozilla). so, pyjamas developers can develop > applications to run in web browsers (compiled to javascript) _or_ they can run > them as desktop apps... > > .... no longer using webkit, but using mozilla technology instead. > > > the next step would be to post a new monolithic patch for review > > addressing feedback in Comment #191 and Comment #194. > > ok. the comments are related to a (highly modified) patch which i could not > get involved in, because of the removal of the event handling. > > so, *sigh* it's necessary to take two steps back in order to take one step > forward, for which i apologise (both to you, and to adam - sorry, adam, but > removing the event handling, i know why you did it, as it took me three days to > update to the latest svn, last week, but i have to work from what i know and > what i can prove works). > > so i'll endeavour to address the comments where they are relevant. > > one immediately that can be addressed: custom attributes. > > > > + if ($attribute->signature->extendedAttributes->{"Custom"} || > > > + $attribute->signature->extendedAttributes->{"CustomGetter"} || > > > + $attribute->signature->extendedAttributes->{"CustomSetter"}) { > > > + return 1; > > > + } > > > [Custom] and related attributes are only used for implementing JS specific > > quirks and should not be needed for GObject bindings. > > the assertion that they are JS-relevant-only is not true, and you can > test this by removing the "custom" test in the generator, and trying to > add everything. > > i found this out myself by accidentally removing it, thanks to an > error in the generator logic, whoops :) so - to demonstrate this to you, sam, i'm trying out the removal of the code from the generator that tests for custom attributes. and immediately you get this: DerivedSources/gdom/GdomDOMWindow.cpp:625: error: ‘class WebCore::DOMWindow’ has no member named ‘event’ WebCore::DOMWindow() _has_ no function "event()", which is correct! because.... it's a custom function! and, if we were to implement that custom function, it would only _increase_ the size of the patch, rather than decrease it. which is contrary to the wishes of the webkit team [and common sense]. so, this should serve to demonstrate to you that there are sound technical and practical reasons for doing what is being done. you are welcome to question each and every single one of the technical decisions: i can tell you right now that we will be here for a loooong time. or, we can land the patch and then retro-grade fix any issues, which i am still willing to help do. the choice i leave up to you.

Luke Kenneth Casson Leighton

Comment 235 2009-07-15 12:56:23 PDT

another one, this time from JavaScriptCallFrame.idl: readonly attribute [CustomGetter] DOMString type; removing the code that checks for (and thus allows) CustomGetters, CustomSetters and Custom properties, results in: DerivedSources/gdom/GdomJavaScriptCallFrame.cpp:211: error: no matching function for call to ‘GStringConvert(JSC::DebuggerCallFrame::Type)’ why? because this is, in javascript-land, a _custom_ function that performs conversion from JSC::DebuggerCallFrame::Type to string. so, on a case-by-case basis, various properties get skipped like this, and i'm just going through them now.

Luke Kenneth Casson Leighton

Comment 236 2009-07-15 13:45:26 PDT

(In reply to comment #214) > After re-reviewing some of the comments, I think my comment that the patch > "must be broken up in to smaller pieces" may be worded too strongly. In > Comment #76, breaking up the patch is suggested as a best practice for new > contributors and will lead to quicker turnaround (reviews) on posted patches, > but it's not a strict requirement. > > However, since you're unwilling to break it up (and since willing to be > patient), the next step would be to post a new monolithic patch for review > addressing feedback in Comment #191 and Comment #194. ok - so, as we know, due to a misunderstanding, that happened, but it was believed that adam's work would be the way to move forward. given that far too much was removed to make that possible, and given that my knowledge of eight months ago is of the original patch, i went from the original patch. so, with my original intentions to help move this forward still standing, but on a basis where i can actually contribute stuff that is useful to its users (pywebkitgtk and pyjamas-desktop) and so i can genuinely say, "yes, i can show and prove that this works, reliably", i ask you this question: what, dave, would it take? i.e. what would you be willing to offer that moves this forward? use of adam's work as the initial basis is sadly not acceptable (to me as a free software contributor, or to pyjamas-desktop developers) and, given that i'm the one that's offering to contribute, you should (necessarily) take that into consideration. here are some suggestions, and i would welcome input from anyone with any other ideas: 1) a patch that makes the current libwebkitgdom.la a totally separate library, external to and absolutely nothing to do with webkit - not even maintained by webkit, not part of webkit. for this to happen, an opaque entrypoint function will be required, to get at probably..... DOMWindow. or, a "setter" function will be required to set the pointer to Frame*. and, critically, the CodeGenerator bindings scripts will need to be possible to run as separate stand-alone applications, and the IDL files will need to be installed in /usr/share/webkit/.... somewhere. (this latter is exactly what XULrunner does, btw, because you need the IDL files from xulrunner for COM c++ application development. conceptually, there is no difference here). the nice thing about this is that if people want to shoot themselves in the foot by sticking to W3C standards, they can; if they want to put webkit-glib bindings onto a par with XulRunner's XPCOM bindings and with MSHTML's DCOM bindings, they can. 2) a list of minor features - a compromise between what you believed we were agreeing to and what i believed that we were agreeing to - which would be acceptable to add prior to proceeding as agreed with landing the rest as-is. anyone can then take a look at the list - including myself - and see which items are time-consuming and which are manageable. the disadvantage of this approach is that each and every time a patch is submitted, you have _yet another_ massive review to perform, just to get things to the point where the patch can be landed [with some issues still to be dealt with] it has to be ironically pointed out that this overhead could be mitigated by landing the patch, of course, and then following up with smaller patches, but if there is a desire to stick to procedures, even if it causes stress and distress, then i'm not going to stop you - just don't lay the blame at my door if things remain too much. however, what might work would be to submit "patches-to-patches" for review, i.e. take the current patch as-is (attachment 32633 [details]) and we agree that "minor feature" patches will be reviewed. if the complete list of "minor feature" patches is fulfilled, then the attachment 32633 [details] plus the accompanying minor-patches are landed "as-is", and then we move forward to fix any other remaining outstanding (larger) issues. this is... sort of a less formal / less strict version of 4) or 5) below. 3) we wait - for someone else to come up with the goods. i'm quite happy to do this - it's just that... we end up with disappointed and frustrated users by doing so. i can manage doing .deb builds of webkit-glib/gobject for 32-bit and 64-bit debian users, and i can do customised/embedded builds. and even macports.org builds. but... windows? pshahh. tried it once. took eight days. not me 'guv :) so - we wait, but waiting delays delivery. fortunately, for pyjamas-desktop users, there is always xulrunner, so it's the other projects that suffer. 4) a branch. the patch is landed as-is.... in a branch. in that way, people can contribute merges and fixes, and move forward. merges are the biggest time-consumer of all, way beyond making modifications. one of the primary motivations behind my recommendation that the patch be landed and then worked on post-landing is due to the fact that merges, using anything-other-than-webkit-svn, is tricky and time-consuming. by working from a webkit branch _in_ the webkit svn, there are several distinct advantages: a) the burden of merges goes away b) the work is still being carried out in one "central" location under the watchful eye of the webkit team c) the review process can still be carried out, as usual. 5) work is carried out elsewhere (not using webkit svn) patches and reviews take place elsewhere, but continuing to utilise the bugtracker, here. smaller patches could be submitted for review (here), with reviewers being made keenly aware that they are reviewing an external source tree not a webkit one, with a view to it being accepted _by_ webkit. in this way, the process of development of the work is acceptable and manageable; the eventual acceptance is trustworthy. disadvantage: disconnect between webkit svn and whereever-it-is, making merges timeconsuming (and cumbersome). 6) other. thoughts? i'm interested to hear from anyone at all, world-wide, who is willing to help make sound strategic or technical contributions to this discussion, with a view to providing useful and useable c-based glib/gobject DOM bindings.

Luke Kenneth Casson Leighton

Comment 237 2009-07-15 13:58:35 PDT

Created attachment 32807 [details] answering comments in #194 by sam ok - sam, this is answering the question about why CustomGetter, CustomSetter and Custom are used. if you don't then there are three (that i could find, through compile-errors) properties that have to be skipped; i just skip anything of type "Event"; anything of type "Object" and JavaScriptCallFrame.type. i'm not sure of the wisdom of skipping everything of type "Event", it may be wiser to skip only "DOMWindow.event" but i wanted to solicit your approval for this technique of removing the references to CustomGetter, CustomSetter and Custom in favour of very specific statements like this: + # skip JavaScriptCallFrame.type + if (($prop_name eq "type") && ($interfaceName eq "JavaScriptCallFrame")){ + next SKIPPROP; + } there aren't tooooo many of these, as you can see, but it can also be seen that they are, right now, entirely necessary. and the patch size is kept down as a result. l.

Sean Neilan

Comment 238 2009-07-15 14:32:07 PDT

My goodness, LKCL, stop talking so much. I'm very interested in the progress of this bug, but, in the time spent spamming, a lot of progress could've been made. I was on your side before (and thought there were sides in this thing!) but I realize that you need better people skills if you want this to go anywhere. I'll fix this patch myself once I have the time. Couldn't be that hard.

David Kilzer (:ddkilzer)

Comment 239 2009-07-15 16:48:35 PDT

(In reply to comment #236) > what, dave, would it take? > i.e. what would you be willing to offer that moves this forward? Sorry, I have nothing more to add that wouldn't be restating the obvious.

Luke Kenneth Casson Leighton

Comment 240 2009-07-16 01:49:13 PDT

(In reply to comment #238) > My goodness, LKCL, stop talking so much. I'm very interested in the progress of > this bug, but, in the time spent spamming, a lot of progress could've been > made. teeelll me about it. ... actually, don't - that would be in breach of agreement to keep to technical issues :) > I was on your side before (and thought there were sides in this thing!) but I > realize that you need better people skills if you want this to go anywhere. i'm absolutely aware of that. [explanation cut in order to keep to agreement to discuss technical issues.] > I'll fix this patch myself once I have the time. Couldn't be that hard. ha ha that's the spirit :) [btw that's exactly what i said about nt domains reverse-engineering...] time _is_ the key, here. there have been only three contributors - four including the absolutely invaluable technical review input from mark rowe. it'd be nice to have a fifth. when you have time, then do, like martin did, use the pywebkitgtk patch as the "sounding board". indirectly via pywebkitgtk, pyjamas-desktop is the only significant "user" of these bindings at the moment, which makes it the code-coverage and testing platform.

Luke Kenneth Casson Leighton

Comment 241 2009-07-16 03:47:52 PDT

(In reply to comment #240) > (In reply to comment #238) > > My goodness, LKCL, stop talking so much. I'm very interested in the progress of > > this bug, but, in the time spent spamming, a lot of progress could've been > > made. > > teeelll me about it. ... actually, don't - that would be in breach of > agreement to keep to technical issues :) > > > I was on your side before (and thought there were sides in this thing!) but I there are no "sides" - there is only the goal. the goal is "useable and useful gobject / c DOM bindings". i freely admit that i'm pathologically focussed on that goal and that goal alone. > > I'll fix this patch myself once I have the time. Couldn't be that hard. > > ha ha that's the spirit :) [btw that's exactly what i said about nt domains also, if you're limited on time, and also simply from a practical perspective, can i recommend the use of a joint / collaborative repository to which we both have access? as you know i'm currently using github - you or anyone else i'm happy to grant commit / push access but if you or anyone else has any other suggestions i'm happy to work with that. in that way, if you don't have time, i can perform the necessary high-level testing which will help keep the patch on-track. just because following webkit's procedures have resulted in stress and distress [that my unfortunately-ignored recommendations were made to avoid] doesn't mean that _you_, sean, should subject yourself to the same levels of stress.

Luke Kenneth Casson Leighton

Comment 242 2009-07-16 03:54:56 PDT

(In reply to comment #239) > (In reply to comment #236) > > what, dave, would it take? > > i.e. what would you be willing to offer that moves this forward? > > Sorry, I have nothing more to add that wouldn't be restating the obvious. dave, hi, i'm sorry to hear that. i'm very grateful that you were willing to make a committment to move this issue forward. i can surmise that you were, in some way, acting as a conciliatory intermediary. so that there is no misunderstanding, please do risk stating what you believe to be obvious, because as you should be aware by now i am very literal-minded. and, as a software engineer, i _never_ take "the obvious" for granted. we've just _had_ one round of agreement where there were misunderstandings. perhaps might i suggest that you simply answer the question? nobody will think that you are stating the obvious, and nobody will be critical of you for doing so. far from it: they will actually respect you enormously for being the one willing to move this issue forward. l.

Luke Kenneth Casson Leighton

Comment 243 2009-07-16 04:19:34 PDT

(In reply to comment #242) > (In reply to comment #239) > > (In reply to comment #236) > > > what, dave, would it take? > > > i.e. what would you be willing to offer that moves this forward? > perhaps might i suggest that you simply answer the question? nobody will > think that you are stating the obvious, and nobody will be critical of you > for doing so. far from it: they will actually respect you enormously for > being the one willing to move this issue forward. ohohoh, one _very_ important factor to take into consideration, when thinking about and formulating your answer: * how should the approach [in your recommendation] be _tested_ ? with the [empirical?] testing environment locked up [in a proprietary company, intellectual property of yorba.com] which only adam had access to, how is anyone supposed to move adam's work forward? at least pywebkitgtk is free software, as is pyjamas-desktop. behind pyjamas-desktop is a widget-set API based on DOM bindings to python. that widget set API is 8,000 lines of dedicated python. then, there are the examples themselves, comprising what is now about twenty five examples at around... i guess... 10,000 lines of test code. so - in answering the question, _do_ take into consideration that if the way forward that you recommend does _not_ involve using the current work, but involves moving forward from adam's work, that you will be asking people to work without a test suite, until such time as the work can be brought up to standard. this is what i thought was obvious when we made an agreement, and i apologise for not realising that you might not think that was so. i mention this to highlight why it might not be a good idea to assume that things are obvious, and i look forward to your reply.

Adam Dingle

Comment 244 2009-07-16 04:44:10 PDT

> with the [empirical?] testing environment locked up [in a proprietary company, > intellectual property of yorba.com] which only adam had access to, how is For the record, Yorba is a non-profit group which makes only open source software. All of its work is licensed under the LGPL and freely available at svn://svn.yorba.org .

David Kilzer (:ddkilzer)

Comment 245 2009-07-16 08:39:32 PDT

(In reply to comment #242) > (In reply to comment #239) > > (In reply to comment #236) > > > what, dave, would it take? > > > i.e. what would you be willing to offer that moves this forward? > > Sorry, I have nothing more to add that wouldn't be restating the obvious. > perhaps might i suggest that you simply answer the question? Break up the patch into pieces so that each piece may be reviewed, revised, and committed. Since you've already committed to maintaining a big patch against WebKit trunk indefinitely, breaking it up into smaller pieces that are committed to trunk dovetails nicely with this process. As each small patch is committed to trunk, your large patch against trunk will shrink when you rebase. You'll also find any issues that may have crept into trunk since you'll still be able to test the full, rebased patch in your environment. It will also be easy to address any such issues in the next small patch. Also note that new features added to WebKit don't have to be complete when they initially land. Take DataGrid as a recent example. The first commit just added empty stub files and updated build files to make sure they compiled on every port. <http://trac,webkit.org/changeset/44778> Future patches built on that initial commit to implement the feature. May I suggest that you file a new bug for each smaller patch and relate it back to this bug?

Jan Alonzo

Comment 246 2009-07-18 01:09:08 PDT

Comment on attachment 32633 [details] brings glib/gobject bindings up to svn r44473. This patch did not address the feedback made by other reviewers. Please make it short and sweet so it can be reviewed thoroughly.

Jan Alonzo

Comment 247 2009-07-18 01:15:04 PDT

Comment on attachment 32807 [details] answering comments in #194 by sam This patch is missing a ChangeLog and can't be r+d as it is, so r-. Please submit a patch that actually builds and addresses the issues raised by other reviewers. Thanks.

Luke Kenneth Casson Leighton

Comment 248 2009-07-18 02:14:36 PDT

(In reply to comment #247) > (From update of attachment 32807 [details]) > This patch is missing a ChangeLog and can't be r+d as it is, so r-. Please > submit a patch that actually builds and addresses the issues raised by other > reviewers. > > Thanks. jan, hi, thank you for looking at this. (In reply to comment #244) > > with the [empirical?] testing environment locked up [in a proprietary company, > > intellectual property of yorba.com] which only adam had access to, how is > > For the record, Yorba is a non-profit group which makes only open source > software. All of its work is licensed under the LGPL and freely available at > svn://svn.yorba.org . BRILLIANT! that's fantastic news - so that means that there is a second test-path available for anyone who would like to work on this, from where you left off, adam. that's really good to hear. l.

Luke Kenneth Casson Leighton

Comment 249 2009-07-18 02:20:13 PDT

(In reply to comment #245) > (In reply to comment #242) > > (In reply to comment #239) > > > (In reply to comment #236) > > > > what, dave, would it take? > > > > i.e. what would you be willing to offer that moves this forward? > > > Sorry, I have nothing more to add that wouldn't be restating the obvious. > > perhaps might i suggest that you simply answer the question? > > Break up the patch into pieces so that each piece may be reviewed, revised, and > committed. > > Since you've already committed to maintaining a big patch against WebKit trunk > indefinitely, breaking it up into smaller pieces that are committed to trunk > dovetails nicely with this process. As each small patch is committed to trunk, > your large patch against trunk will shrink when you rebase. You'll also find > any issues that may have crept into trunk since you'll still be able to test > the full, rebased patch in your environment. It will also be easy to address > any such issues in the next small patch. ooo. that. is a very good idea. > Also note that new features added to WebKit don't have to be complete when they > initially land. Take DataGrid as a recent example. The first commit just > added empty stub files and updated build files to make sure they compiled on > every port. <http://trac,webkit.org/changeset/44778> Future patches built on > that initial commit to implement the feature. okaay. so - something like starting with CodeGeneratorGObject.pm and going from there. > May I suggest that you file a new bug for each smaller patch and relate it back > to this bug? veeery good idea. then each issue / submission gets done separately [and cleanly] i like it. to help those people willing to contribute, i will continue to submit the "large" version, here, but without review flags.

Luke Kenneth Casson Leighton

Comment 250 2009-07-18 02:44:51 PDT

(In reply to comment #246) > (From update of attachment 32633 [details]) > This patch did not address the feedback made by other reviewers. Please make it > short and sweet so it can be reviewed thoroughly. jan, hi, thank you for looking at this. my apologies for not cross-referencing them accurately, but the feedback _has_ been addressed: it's just that: a) in some of the responses, i don't go "yes, i will do that", i say, "no, that would be a bad idea, and this this and this is why. please can you answer if you agree / understand / accept". on some of those issues, i am still, after eleven separate requests for feedback, awaiting a response. b) the sheer number of issues raised on something that i did say, well in advance, "this is very very involved", means that both of us miss things. [not that that's terribly important (details-wise) because of the extensive and high-level empirical testing that's been done, but... i fully appreciate that missing things out makes people nervous]. so, i would _love_ to keep it short - but to do so risks omissions, and we fall between a rock and a hard place. _but_ - since you sent this, david proposed a way forward (which is _great_) which i think will work very well: submission of portions of this work, as separate patches and bugreports. i'm starting with #27410, which is the "biggie" - the code generator. once that's in, everything else will fall into place around it.

Luke Kenneth Casson Leighton

Comment 251 2009-07-18 10:43:07 PDT

(In reply to comment #90) > > That may be what your project is about, > > it's "my" project, it's _a_ project that i happen to be > working on, at present. correction - that sentence was intended to start, ' it's not "my" project ...' gosh, how did i miss that?

Luke Kenneth Casson Leighton

Comment 252 2009-07-18 14:24:08 PDT

(In reply to comment #147) > (In reply to comment #145) > So only send(in Document data) is available at the moment. You might be able > to use that to do AJAX now: from any Document object you can get a > DOMImplementation, which you could possibly use to construct new Document > objects containing arbitrary text. I haven't tried that myself, however. sorry adam i've only just found these comments! i did try [create a new Document object] and the attempts resulted in segfaults and consumed significant time and resources. so - LANGUAGE_GOBJECT re-enables send(DOMString), pending a solution [post-landing]. sadly, the policy on webkit bugreports is that you are not allowed to record bugs onto bugreports that have not been landed. so, we must make a mental note of this, along-side dozens of other issues. > (a) have the bindings generators derive alternate names automatically, e.g. > send_DOMString() and send_Document(), and/or (b) add IDL attributes that > suggest alternate names. I'd love to see that happen, but I think that's > beyond the scope of this first GObject/DOM iteration. very much so.

Wouter Bolsterlee

Comment 253 2009-07-19 13:33:42 PDT

Removing from CC, because the signal/noise ratio is asymptotically approaching 0… Good luck, because this is a very interesting subject.

Luke Kenneth Casson Leighton

Comment 254 2009-07-19 14:04:29 PDT

(In reply to comment #253) > Removing from CC, because the signal/noise ratio is asymptotically approaching > 0… Good luck, because this is a very interesting subject. *lol*. thank you, wouter - heck, you won't see this unless you look for it. the series of "small patches" has begun, but even there, you'd get a lot of messages due to them all being added to #16401. apologies...

Luke Kenneth Casson Leighton

Comment 255 2009-07-19 17:00:21 PDT

ok whoaaa, my head is spinning from creating so many patches. it's still not done - there's the GNUMakefiles.am patches. now at least there are smaller sets of work which people can look at [and in some cases fight over, which has begun already]. at least however the bun-fights will be contained and will no longer spill over into _this_ bugreport, thank god. the goal is: "useable and useful gobject bindings". i'll be making sure that happens, no matter how much people may want to make that a difficult task. anyone who would like to enter into discussions about what is "useful" and what is "useable" regarding gobject bindings, please name a suitable place and i will be happy to engage with you in technical and strategic discussions. as it's a fairly obvious place, i'd recommend the individual bugreports, now that they are subdivided, unless anyone has any better ideas. also, the subdivided bugreports are a good place where anyone interested can make smaller individual contributions that would help landing them. for example, i am giving some thought and consideration to breaking up the GNUmakefile.am patches so that people can look at adam's excellent work and bring it in. also there are a couple of bugreports with hand-coded files that could do with auto-generators, those would be _great_ to do properly: the individual bugreport is the best place to see what needs to be done. overall the suggestion, david, to split this up into separate patches was very very welcome, but i couldn't do it _until_ it was someone _inside_ the webkit team who suggested it. the reason: attempts to utilise the bugtracker in a way in which bugtrackers are supposed to be used were met with crack-downs (close; invalid; wontfix etc.) and hostility by other webkit team members. so, i am _really_ grateful to you for making everyones' lives that much easier.

Luke Kenneth Casson Leighton

Comment 256 2009-07-25 15:10:58 PDT

Created attachment 33497 [details] the monster (complete patch) updated to r46395, including reflected properties this patch isn't being submitted for review, it's here for the convenience of people who want to keep track of things, but to be honest you're better off getting the code from github.org/lkcl/webkit/16401.master

sascha.dewald

Comment 257 2009-12-12 08:06:11 PST

(In reply to comment #256) > Created an attachment (id=33497) [details] > the monster (complete patch) updated to r46395, including reflected properties > > this patch isn't being submitted for review, it's here for the convenience of > people who want to keep track of things, but to be honest you're better off > getting the code from github.org/lkcl/webkit/16401.master does the patch or the git source, work with the currently build of webkit? i really want to have gdom bindings for webkit ... i think this would us bring a step forward against m$.

Xan Lopez

Comment 258 2010-01-13 05:04:15 PST

*** This bug has been marked as a duplicate of bug 33590 ***

Note You need to log in before you can comment on or make changes to this bug.