Bug 153786 - [GTK] Use G_TYPE_ERROR instead of G_TYPE_POINTER for GError parameters of signals
Summary: [GTK] Use G_TYPE_ERROR instead of G_TYPE_POINTER for GError parameters of sig...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P3 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-02 06:31 PST by Iñaki García Etxebarria
Modified: 2016-02-18 19:51 PST (History)
7 users (show)

See Also:


Attachments
Patch (4.78 KB, patch)
2016-02-18 05:53 PST, Carlos Garcia Campos
mcatanzaro: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Iñaki García Etxebarria 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*".
Comment 1 Michael Catanzaro 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....
Comment 2 Iñaki García Etxebarria 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.
Comment 3 Carlos Garcia Campos 2016-02-18 05:53:04 PST
Created attachment 271655 [details]
Patch
Comment 4 WebKit Commit Bot 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
Comment 5 WebKit Commit Bot 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.
Comment 6 Michael Catanzaro 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."
Comment 7 Carlos Garcia Campos 2016-02-18 08:12:28 PST
Committed r196755: <http://trac.webkit.org/changeset/196755>
Comment 8 Iñaki García Etxebarria 2016-02-18 19:51:08 PST
Wonderful, thanks!