[webkit-gtk] WebKit2 GTK+ API

Alexandre Mazari amazari at igalia.com
Fri Sep 16 00:29:45 PDT 2011


Hi Carlos,

Great that with the transition to wk2, we have the occasion to rethink a
bit the API.

As stated in https://bugs.webkit.org/show_bug.cgi?id=61140#c22 , we
might use this occasion to rethink our current (over) usage of signals
and properties.
WebView API currently suffers, IMHO, from having so much unrelated data
and codepath delegation. This do not enforce a clean OO model on both
webkit's and API user's code. Both of them going mostly procedural, have
huge LoC count and fiddle with data sharing. Also we currently flatten
the WebCore object model by putting so much in one class.

Also, most of those signals will have only one listener in the client
code, rendering signals multiplexing/marshalling useless.

We should enforce the user code to be smaller independent testable parts
instead.

Related delegators (currently signals) could go into interface instead.
Implementations of those would then be provided and used by the webview.
Don't call us, we call you...
So for example we could have the following instead of the current
signals:

interface WebKitNotificationPresenter {
	def authRequested (...);
	def checkAuth (...);
	def showNotification (...);
	def cancleNotification (...);
}
and WebKitWebView::setNotificationPresenter
(WebKitNotificationPresenter)

The API user would then provide an implementation of the interface.

Advantages:
- The code and data related to the topic (here notifications) are
isolated
- the class can be tested separately
- the code is more readable, so are stacktraces
- no more intermediate struct types to pass as user_data to callbacks,
everything is in the class
- limoit the scope of sides effects
- the lifecycle of such a delegator class is easier to handle than
multiple data structures.

Cons:
- GObject interface implementation is cumbersome, but this is mitigated
by bindings

I have the feeling signals have bee overused in webkit (and elsewhere in
the platform) for this exact reason. C/GObject low-level complexity
often divert dev from nice oo design for convenience. But that make
testing and maintaining harder, I guess. OT: Vala looks like an
interesting solution to alleviate that.

> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk




More information about the webkit-gtk mailing list