[webkit-gtk] WebKit2 GTK+ API

[Alexandre Mazari]

Some other advantages just came to mind:
- easier code sharing between API clients. Midori and Ephy could share a
common NotificationPresenter/StatusWatcher/... for example
- easier to inject stubs for unit testing
- let the compiler do the typechecking for us by avoid gpointer casts
- ...

Obviouslt signals have there use for unscheduled/unexpected events. But
in most case, method calls is a good way to pass control flow to user
code ;)


Le vendredi 16 septembre 2011 à 09:29 +0200, Alexandre Mazari a écrit :
> 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
> 
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk