WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
Bug 20632
WebKitWebFrame should be replaced with GdomFrame
https://bugs.webkit.org/show_bug.cgi?id=20632
Summary
WebKitWebFrame should be replaced with GdomFrame
Luke Kenneth Casson Leighton
Reported
2008-09-03 13:30:56 PDT
... or the other way round. GdomFrame contains auto-generated the complete set of bindings, whereas WebKitWebFrame is manually created glib code.
Attachments
Add attachment
proposed patch, testcase, etc.
Alp Toker
Comment 1
2008-09-13 07:17:18 PDT
(In reply to
comment #0
)
> ... or the other way round. > GdomFrame contains auto-generated the complete set of bindings, whereas > WebKitWebFrame is manually created glib code. >
The core WebKit/GTK+ API is intentionally hand-written to provide a tailored interface for developers. There isn't anything in the DOM that would work as a good replacement for WebKitWebFrame without customisation so the convention in WebKit ports is to provide accessors to the DOM binding from the core API rather than trying to use the DOM directly for all interaction with the browser engine.
Luke Kenneth Casson Leighton
Comment 2
2008-09-13 09:06:08 PDT
sorry, i'd forgotten about this bugreport - i've since worked out that a much better suggestion would be for WebKitWebFrame to _use_ GdomFrame. i.e. rather than having a Frame* have a GdomFrame*. the reasoning is that there are a number of _functions_ which are hand-created in WebKitWebFrame which could be replaced with the gdom_frame_* equivalents. plus, in some cases, especially the Location* ones - i remember seeing someone talking on the irc about doing a URL class or something, for WebKitWebFrame - of course, you now have gdom_location_* ok - actually, you _don't_ have gdom_location_* yet because it's a custom function in JSLocation which i haven't cut/paste over to GDOM* yet.... ) ... but you get the idea. also, it would make it clearer to the qt porters that the possibility exists to do exactly the same trick in there. yes, they might squawk a bit at #include <gobject.h> their competitor, but that would kick them into gear to do a Qt bindings generator. if WebKitWebFrame itself continues to have a Frame* then it remains unclear as to exactly how other ports should go about adding in the gdom bindings.
Martin Robinson
Comment 3
2010-09-10 08:08:29 PDT
I think that we want to follow the behavior of other ports here and keep them as seperate entities.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug