[Webkit-unassigned] [Bug 15691] [GTK] Public API does not follow GTK+ conventions

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=15691


alp at atoker.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alp at atoker.com




------- Comment #4 from alp at atoker.com  2007-11-22 20:20 PDT -------
In the WebKit GTK+ port's public API today, we have types and functions named
like this:

  WebKitPage
  WebKitFrame
  WebKitNetworkRequest

  WebKitFrame *
  webkit_page_get_main_frame (WebKitPage *page);

We want to move away from this because:

  (1) "WebKitPage" doesn't follow GTK+ conventions. Widgets that are usually
packed in a GtkScrolledWindow and represent a view are called GtkTextView,
GtkTreeView, GtkIconView etc.

  (2) In some language bindings, "WebKit" would be considered the namespace and
you'd be left with generic top-level type names like "Frame" which would
annoyingly conflict with "Frame" from, say, the Gtk namespace.

  (3) What is a "Page"? Is it data? Is it a widget? It's too ambiguous.

So, we want to move to a naming convention similar to that of the Win and Mac
ports. This means providing top-level types named *WebView and *WebFrame.

However, if we keep the current namespace "WebKit", things start to get verbose
and repetitive:

  WebKitWebView
  WebKitWebFrame
  WebKitNetworkRequest

  WebKitWebFrame *
  webkit_web_view_get_main_frame (WebKitWebView *view);

One alternative proposed is simply to prepend "G" (though this looks like
namespace pollution to me):

  GWebView
  GWebFrame
  GNetworkRequest

  GWebFrame *
  g_web_view_get_main_frame (GWebView *view);

Another proposal is to follow the example of GTK+. GIMP ToolKit shortens to
"Gtk" in the API, so we'd follow suit and use the namespace "Wk":

  WkWebView
  WkWebFrame
  WkNetworkRequest

  WkWebFrame *
  wk_web_view_get_main_frame (WkWebView *view);

Whether we go for one of these schemes or a better proposal comes along, the
API chosen now will probably be around for a few years to come. If you have a
preference or disagree with my analysis, please speak up!


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.