Signals and callbacks with parameters

[mdimec4]

Hello First I would like to thank you for all your previous help. I am having a problem with catching a webkit2 "load-changed" signal using gotk3 bindings. Callback function is called with load event information, when WebKitWebView load-changed event happens. http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#WebKitWebView-load-changed

I am probably doing something wrong but if I try the following code. The event value is always 0.

webView.Connect("load-changed", func(_ *glib.Object, event int) {
        loadEvent := LoadEvent(event)
        switch loadEvent {
        case LoadFinished:
            ...
        }
    })

And I always get this message when callback is executed.

(webkit2.test:6801): GLib-GObject-CRITICAL **: g_value_get_int: assertion 'G_VALUE_HOLDS_INT (value)' failed

Some extra information: I am trying to use https://github.com/sourcegraph/go-webkit2 webkit2 biding with newer release of gotk3 than go-webkit2 originally uses. I guess that should not be such a problem. The code actually compiles without problems. At the moment this seams to be the only problem.

[jrick]

Hi, sorry I haven't been able to take a look at this sooner, been busy with another project.

I don't have access to webkit2 at the moment (hopefully that changes soon - I'd like to rewrite xombrero with webkit2 and probably gotk3 too), but I'll play around with the callback parameters for some other GTK code in the next few days to see what might be going wrong.

[mdimec4]

Ok tnx. When I resolve this. I am planing to ask go-webkit2 maintainer. To update go-webkit2 so it could be used with newer version of gotk3.

[mdimec4]

go-webkit2 branch that uses newer gotk3 branch. (from last week) https://github.com/visionect/go-webkit2

[mdimec4]

Hello Have you found anything? Have you encountered the same problem?

[mdimec4]

I have found the bug. In function GoValue() g_value_get_enum() needs to be used to get the enum value. https://github.com/visionect/gotk3/blob/da3b693928fa13a9ea32880b0ce1aaefb2fc3d42/glib/glib.go#L991

[jrick]

Thanks for investigating this; I'll squash+rebase those changes now.

[mdimec4]

Ok no problem In later commits I have also separated types like case TYPE_UINT, TYPE_ULONG, TYPE_FLAGS: I asume the same goes for them to.