Changes between Version 5 and Version 6 of HackingGtk

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

Add an API rationale


  • 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.
     66== API rationale ==
     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.
     70=== WebKitPage ===
     72This will likely soon be renamed to WebKitWebView ( matching GtkTextView, GtkTreeView etc. on the GTK+ side and WebView in the Mac and Win ports of WebKit.
     74=== WebKitFrame ===
     76Currently very similar to WebFrame, this is a headless representation of a browser frame, rather than a GtkWidget like WebKitPage.
     78=== WebKitNetworkRequest ===
     80Very limited right now but this can be considered the beginning of a public API to access the underlying HTTP stack.
     82=== WebKitWebSettings ===
     84The future of WebKitWebSettings is uncertain. We might not want to do settings like this at all.
    6686== The build bots ==