| | 1 | Heres some thoughts if you are thinking about Gtk -style API for Webkit which would run on top of Gdk/Gtk+ or similar environment. I'm not sure what desired for WebkitGdk, since the port's name is Gdk and not Gtk+. Nevertheless, since the code seems to have dependency to Gtk+, I'll ramble anyway. |
| | 2 | |
| | 3 | I created webkit-gtk api for gtk-webcore. It's copied from WebKit's WebView API, translated to GObject -like API using same conventions that all the Gtk+ and GNOME applications use. |
| | 4 | Currently the main classes are: |
| | 5 | |
| | 6 | * WebkitView (which corresponds to WebView), the main view which can show web pages. This is a GtkWidget you can put to the application layout |
| | 7 | * WebkitFrame (corresponds to WebFrame), class representing a frame in a web page. WebView has one main frame, and main frame can have multiple child frames. |
| | 8 | * WebkitUIDelegate, WebkitResourceLoadDelegate, WebkitFrameLoadDelegate: hooks into various processes the engine does |
| | 9 | |
| | 10 | The main assumptions in this api are as follows: |
| | 11 | * if a library targets gtk applications, it needs to have gtk api that feels native. This means C, this means GObject system and this means Gtk coding standards *for the API* |
| | 12 | * if a library implementation is based on Webkit, it should reflect webits implementation. Trying to swim against the current (ie. doing things differently than Obj-C Webkit) is just asking for trouble. And WebView is a good API. |
| | 13 | |
| | 14 | These are actually written and in use in gtk-webcore's NRCit public API. This component corresponds what would be WebkitGdk, public API for developers using the WebkitGdk component. |
| | 15 | |
| | 16 | http://gtk-webcore.svn.sourceforge.net/viewvc/gtk-webcore/trunk/NRCit/src/webkit-gtk/webkit-view.h?revision=92&view=markup |
| | 17 | 92 |
| | 18 | |
| | 19 | http://gtk-webcore.svn.sourceforge.net/viewvc/gtk-webcore/trunk/NRCit/src/webkit-gtk/webkit-frame.h?revision=92&view=markup |
| | 20 | 92 |
| | 21 | |
| | 22 | http://gtk-webcore.svn.sourceforge.net/viewvc/gtk-webcore/trunk/NRCit/src/webkit-gtk/webkit-ui-delegate.h?revision=92&view=markup |
| | 23 | 92 |
| | 24 | |
| | 25 | The overall API can be found from following URL: |
| | 26 | |
| | 27 | http://gtk-webcore.svn.sourceforge.net/viewvc/gtk-webcore/trunk/NRCit/src/webkit-gtk/ |
| | 28 | |
| | 29 | The header files would apply directly to the Webkit TOT Gdk work. The implementatation (.c and .cc files) of said interface is specific to gtk-webcore. My rationale to implement this in gtk-webcore was twofold: |
| | 30 | * Replace the old webi -api (pasted below, btw) |
| | 31 | * When WebKitGdk would have enough features, developers using gtk-webcore could move directly to WebkitGdk |
| | 32 | |
| | 33 | Above API is not complete copy of WebView in the sense that it is not complete. Rather you should view it as good bare minimum set of classes, functions and conventions to publish before you can write working browser and still not hack into the core of the engine (meaning using webkit or webcore code directly. |
| | 34 | |
| | 35 | Note that when I write here WebkitGdk, I don't mean I want to push WebkitGdk port towards Gtk+ dependencies, Gtk+ style APIs or anything. I just mean that *if* the project aims to be a web content rendering engine for Gtk+ environment, then this kind of API will be needed, and going with WebView is a good alternative. |
| | 36 | |
| | 37 | -- kimmok@iki.fi, Kompo in #webkit |
| | 38 | |
| | 39 | ---- |
