Changes between Version 5 and Version 6 of HackingGtk


Ignore:
Timestamp:
Nov 28, 2007 2:54:21 PM (16 years ago)
Author:
alp@atoker.com
Comment:

Add an API rationale

Legend:

Unmodified
Added
Removed
Modified
  • HackingGtk

    v5 v6  
    6464 * If a method looks strange or out of place, '''ask awkward questions''' until someone explains why it is the way it is. The Mac port may contain deprecated/bad API that exists only for the sake of compatibility -- we want to learn form those mistakes rather than copying them.
    6565
     66== API rationale ==
     67
     68The strategy here is to develop a GObject-based interpretation of the Objective-C API combined with experience working with GtkTextView, GtkHtml and gtkmozembed. This allows us to benefit from the maturity of a widely-deployed API, but demands extra caution not to adopt any of the baggage or legacy that might be present for backward compatibility only. The Win port is also a useful resource but is less suitable for direct inspiration since it hasn't been deployed as a stable API yet and has a large API footprint that would be difficult to support in the long term.
     69
     70=== WebKitPage ===
     71
     72This will likely soon be renamed to WebKitWebView (http://bugs.webkit.org/show_bug.cgi?id=15691) matching GtkTextView, GtkTreeView etc. on the GTK+ side and WebView in the Mac and Win ports of WebKit.
     73
     74=== WebKitFrame ===
     75
     76Currently very similar to WebFrame, this is a headless representation of a browser frame, rather than a GtkWidget like WebKitPage.
     77
     78=== WebKitNetworkRequest ===
     79
     80Very limited right now but this can be considered the beginning of a public API to access the underlying HTTP stack.
     81
     82=== WebKitWebSettings ===
     83
     84The future of WebKitWebSettings is uncertain. We might not want to do settings like this at all.
     85
    6686== The build bots ==
    6787