Bug 14726 - [gtk] API design. Mapping the WebView delegates to signals.
Summary: [gtk] API design. Mapping the WebView delegates to signals.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
: 15357 (view as bug list)
Depends on:
Blocks: 14725
  Show dependency treegraph
 
Reported: 2007-07-23 11:37 PDT by Holger Freyther
Modified: 2007-10-03 10:35 PDT (History)
3 users (show)

See Also:


Attachments
Rename the Gtk+ port API namespace (74.41 KB, patch)
2007-10-03 07:03 PDT, Alp Toker
aroben: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Holger Freyther 2007-07-23 11:37:48 PDT
It is important to design a suitable API for the WebKitGtk port. The primary use case should be browsing and displaying content. The secondary use case will be editing.

The API should follow WebView of the Mac/Windows port both in design and naming of functions. We are free to name the methods slightly different and insert as many '_' as we want.

WebView is using delegates. For the WebKitGtk port these will be mapped to signals. For the informal signals the only decision we have to make is if we want to allow having default handlers in the class of WebKitGtkPage and WebKitGtkFrame.

For delegates like the WebPolicyDelegate we should not use signals with return values but make the decisionListener some kind of GType (boxed,GObject...) that gets passed to the handlers as part of the signal. The first one calling the decisionListener makes the decision.

For delegates like the WebFrameLoadDelegate (responsible for assigning ids) we should consider using return values or pass the 'result' as pointer in the signal. The issue to be discussed is who should be able to stop the emission of the signal, who should be able to make the decision. The first one returning a result, the last one setting a result in the struct?
Comment 1 Holger Freyther 2007-07-23 12:04:08 PDT
Rename the symbols from webkit_gtk to web_ and the files from webkitgtk to web (priority :fix it!!).
Comment 2 Holger Freyther 2007-07-23 13:14:35 PDT
Add the Gtk keyword, even to the curl bugs.
Comment 3 Christian Dywan 2007-07-29 09:24:44 PDT
> Rename the symbols from webkit_gtk to web_ and the files from webkitgtk to web

Please do *not* change it to web_. That would be too generic and therefore unfair against other projects. Think of web_page_new for instance. It might very easily clash with other names.

Instead my suggestion for the scheme would be either webkit_foo or gtk_webkit_foo. I tend to be in favor of gtk_webkit_foo because WebKit is a cross-platform toolkit and omitting the gtk suggests a gtk-specific toolkit imho.
Comment 4 Alp Toker 2007-10-03 05:46:40 PDT
*** Bug 15357 has been marked as a duplicate of this bug. ***
Comment 5 Alp Toker 2007-10-03 06:12:30 PDT
web_ is not a popular option with the developers I've spoken with, due to namespace pollution. wk_ was also suggested but webkit_ seems to be the most sensible option. I wonder now whether the CamelCased form of this namespace should be Webkit or WebKit (ie. WebkitPage vs. WebKitPage)..
Comment 6 Alp Toker 2007-10-03 07:03:39 PDT
Created attachment 16520 [details]
Rename the Gtk+ port API namespace
Comment 7 Adam Roben (:aroben) 2007-10-03 09:41:56 PDT
Comment on attachment 16520 [details]
Rename the Gtk+ port API namespace

If this is truly just a rename as claimed, rs=me. We should rename the files at some point as well (webkitgtkpage.cpp -> webkitpage.cpp)
Comment 8 Alp Toker 2007-10-03 10:35:10 PDT
Fixed in r26022