Changes between Version 3 and Version 4 of GtkAPIProposal


Ignore:
Timestamp:
Apr 20, 2007 12:49:00 PM (17 years ago)
Author:
Kimmo Kinnunen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GtkAPIProposal

    v3 v4  
    44Currently the main classes are:
    55
    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
     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
    99
    1010The 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.
     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.
    1313
    1414These 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.
     
    2828
    2929The 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
     30 * Replace the old webi -api (pasted below, btw, by somebody else)
     31 * When WebKitGdk would have enough features, developers using gtk-webcore could move directly to WebkitGdk
    3232
    3333Above 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.