Changes between Version 5 and Version 6 of HackingGtk

Timestamp:

Nov 28, 2007, 2:54:21 PM (17 years ago)

Author:

alp@atoker.com

Comment:

Add an API rationale

HackingGtk

@@ -64 +64 @@
  * 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.
 
+== API rationale ==
+
+The 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.
+
+=== WebKitPage ===
+
+This 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.
+
+=== WebKitFrame ===
+
+Currently very similar to WebFrame, this is a headless representation of a browser frame, rather than a GtkWidget like WebKitPage.
+
+=== WebKitNetworkRequest ===
+
+Very limited right now but this can be considered the beginning of a public API to access the underlying HTTP stack.
+
+=== WebKitWebSettings ===
+
+The future of WebKitWebSettings is uncertain. We might not want to do settings like this at all.
+
 == The build bots ==