RESOLVED FIXED Bug 153786
[GTK] Use G_TYPE_ERROR instead of G_TYPE_POINTER for GError parameters of signals
https://bugs.webkit.org/show_bug.cgi?id=153786
Summary [GTK] Use G_TYPE_ERROR instead of G_TYPE_POINTER for GError parameters of sig...
Iñaki García Etxebarria
Reported 2016-02-02 06:31:35 PST
The type for the "load-failed" signal of WebKitWebView (in WebKit2): http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#WebKitWebView-load-failed is gboolean user_function (WebKitWebView *web_view, WebKitLoadEvent load_event, gchar *failing_uri, gpointer error, gpointer user_data) Notice that the fourth argument, "error", is of type GError*, but its type is given to be a generic gpointer. This is inconvenient for language bindings, since the type of "error", being a raw pointer, needs to be cast by hand to GError before being usable. The analogous signal in WebKit1 (? The API before WebKit2), WebkitWebView::load-error has the corresponding argument appropriately marked as "GError*".
Attachments
Patch (4.78 KB, patch)
2016-02-18 05:53 PST, Carlos Garcia Campos
mcatanzaro: review+
Michael Catanzaro
Comment 1 2016-02-02 10:44:24 PST
I think it's safe to fix this? I noticed this but left it alone thinking we might break bindings if we change it. If bindings folks want us to change it....
Iñaki García Etxebarria
Comment 2 2016-02-02 10:52:46 PST
(In reply to comment #1) > I noticed this but left it alone thinking we might break bindings if we > change it. If bindings folks want us to change it.... Just FYI, I am the maintainer of the gobject-introspection (GI) bindings for Haskell (which includes the GI-based WebKit2 bindings), and it would certainly be desirable to fix this for us, even if it is an API break. But I cannot speak for other languages, of course.
Carlos Garcia Campos
Comment 3 2016-02-18 05:53:04 PST
WebKit Commit Bot
Comment 4 2016-02-18 05:54:53 PST
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
WebKit Commit Bot
Comment 5 2016-02-18 05:55:00 PST
Attachment 271655 [details] did not pass style-queue: ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitPrintOperation.cpp:205: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitPrintOperation.cpp:207: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitDownload.cpp:269: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitDownload.cpp:271: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:1083: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:1087: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitWebResource.cpp:198: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] ERROR: Source/WebKit2/UIProcess/API/gtk/WebKitWebResource.cpp:200: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3] Total errors found: 8 in 5 files If any of these errors are false positives, please file a bug against check-webkit-style.
Michael Catanzaro
Comment 6 2016-02-18 06:05:26 PST
Comment on attachment 271655 [details] Patch Something to think about in the future, from https://developer.gnome.org/gobject/unstable/howto-signals.html: "The C signal marshaller should always be NULL, in which case the best marshaller for the given closure type will be chosen by GLib. This may be an internal marshaller specific to the closure type, or g_cclosure_marshal_generic, which implements generic conversion of arrays of parameters to C callback invocations. GLib used to require the user to write or generate a type-specific marshaller and pass that, but that has been deprecated in favour of automatic selection of marshallers."
Carlos Garcia Campos
Comment 7 2016-02-18 08:12:28 PST
Iñaki García Etxebarria
Comment 8 2016-02-18 19:51:08 PST
Wonderful, thanks!
Note You need to log in before you can comment on or make changes to this bug.