Bug 75459 – Provide Vala bindings (vapi) for WebKitGTK

• Component: WebKitGTK
• Status: RESOLVED WORKSFORME

[Eric Gregory]

The Vapi file for WebKitGTK that ships with Vala is sorely out of date.  It would be preferable for WebKitGTK to provide its own.

A number of Vala applications rely on WebkitGTK (such a s Shotwell) so this addition would be much appreciated!

[Martin Robinson]

Any idea what the best practice is for shipping VAPI files with your library? Seems fairly simple to add a vapigen build step, we just need to install it somewhere.

[Eric Gregory]

I asked about this on the Vala mailing list.  Marc-André Lureau responded with the following advice:

-----------------------

This is what I would do if the vapi file can be generated directly
from gobject-introspection gir file, then it's rather straightforward:

Add --enable-vala and check for AC_PATH_PROG(VAPIGEN, vapigen) in configure.ac.

Add vapi files rules in Makefile.am (perhaps in a vapi directory):

if WITH_VALA
vapidir = $(datadir)/vala/vapi
vapi_DATA =             \
       webkit-1.0.vapi \
       webkit-1.0.deps

webkit-1.0.vapi: $(top_builddir)/where/to/find/WebKit-1.0.gir
       $(AM_V_GEN)$(VAPIGEN) --library webkit-1.0 $<
endif

Adjust your arguments where needed, add metadata/custum files etc..
Hope that helps!

[Eric Gregory]

It's also been pointed out on the mailing list that bug #49875 needs to be resolved (it includes a patch) before Vapigen can run properly on WebKitGTK.

[Eric Gregory]

Created attachment 123043 [details]
Vapi generation files + script

Here's a demo setup for generating the Vapi.  I'm going to leave integrating all this into WebKitGtk's build system to the experts.

How to use this:
1. Apply Evan's GIR patch.
2. Build and install WebKitGtk
3. Open my gen-vapi.sh script and comment out all but the first call to vala-gen-introspect.
4. Run the script.  YOU WILL ENCOUNTER ERRORS.  This is because the JavascriptCoreGtk headers reference .h files that vala-gen-introspect cannot find.  The easiest thing to do here is to comment out those lines in the headers temporarily.
5. Uncomment the remaining lines in the script and run it again.

Now you should have two shiny new .vapi files!  Yay!

[Evan Nemerson]

Created attachment 123452 [details]
[GTK] Use uninstalled JSCore-3.0 package for creating WebKit-3.0.gir

[Evan Nemerson]

Created attachment 123453 [details]
[GTK] Add Vala bindings

[Evan Nemerson]

(In reply to comment #4)
> Created an attachment (id=123043) [details]
> Vapi generation files + script

This uses GIDL instead of GIR, which we (Vala) are in the process of moving away from.

[Martin Robinson]

Comment on attachment 123453 [details]
[GTK] Add Vala bindings

This looks pretty good to me. Do you mind moving new files into a 'vala' subdirectory?

[Martin Robinson]

Typically we do one patch per bug, but these two patches can probably just be combined.

[Evan Nemerson]

Created attachment 123464 [details]
Patch

[Eric Gregory]

I'm really glad to see the progress on this bug!  My only concern is the metadata file still needs a few tweaks; Vala expects class names to be CamelCased in a certain way.  

Without the proper entries in the metadata, class names such as DOMElement result in gcc errors due to Vala's inability to match the class name to the appropriate type checking and casting macros.

[Evan Nemerson]

Created attachment 123466 [details]
Patch

[Evan Nemerson]

(In reply to comment #11)
> I'm really glad to see the progress on this bug!  My only concern is the metadata file still needs a few tweaks; Vala expects class names to be CamelCased in a certain way.  
> 
> Without the proper entries in the metadata, class names such as DOMElement result in gcc errors due to Vala's inability to match the class name to the appropriate type checking and casting macros.

Can you provide a minimal test case of something that doesn't work with the patch I just uploaded? If you're hitting GCC errors it sounds like a Vala bug, not an issue with the metadata.

[Martin Robinson]

I'll hold off my review here until Eric's response.

[Eric Gregory]

Unfortunately I still haven't been able to test this out.

Over the weekend I found after a few hours that the WebKitGTK SVN repo is hosed; it always choked on some file with a mysterious error message.

So today I checked it out with Git and everything seemed good.  But I'm getting a compile error that appears related to this patch:


Source/WebKit/gtk/webkit/webkitwebplugindatabase.h:51: Warning: WebKit: webkit_web_plugin_database_plugins_list_free: argument list: Missing (element-type) annotation
  GEN    Programs/resources/inspector/inspector.html
  GEN    Programs/resources/inspector/inspector.html
  GEN    JSCore-3.0.typelib
  GEN    WebKit-3.0.typelib
  GEN    Source/WebKit/gtk/vala/webkitgtk-3.0.vapi
/bin/bash: line 1: --library: command not found
make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127
make[1]: Leaving directory `/home/eric/Development/WebKit'
make: *** [all] Error 2


Any idea what could be causing this?

[Martin Robinson]

I'm linking to this thread on desktop-devel-list because there is some minor controversy about whether including vapi files in the library is the way to go: http://mail.gnome.org/archives/desktop-devel-list/2012-January/msg00086.html I don't have much of an opinion on the matter, but it might be good to wait until the thread plays out.

[Evan Nemerson]

(In reply to comment #15)
> Unfortunately I still haven't been able to test this out.
> 
> Over the weekend I found after a few hours that the WebKitGTK SVN repo is hosed; it always choked on some file with a mysterious error message.
> 
> So today I checked it out with Git and everything seemed good.  But I'm getting a compile error that appears related to this patch:
> 
> 
> Source/WebKit/gtk/webkit/webkitwebplugindatabase.h:51: Warning: WebKit: webkit_web_plugin_database_plugins_list_free: argument list: Missing (element-type) annotation
>   GEN    Programs/resources/inspector/inspector.html
>   GEN    Programs/resources/inspector/inspector.html
>   GEN    JSCore-3.0.typelib
>   GEN    WebKit-3.0.typelib
>   GEN    Source/WebKit/gtk/vala/webkitgtk-3.0.vapi
> /bin/bash: line 1: --library: command not found
> make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127
> make[1]: Leaving directory `/home/eric/Development/WebKit'
> make: *** [all] Error 2
> 
> 
> Any idea what could be causing this?

Try installing vala from git master so you get the vapigen pkg-config file. If that resolves it I'll update the patch (just need to do PKG_CHECK_MODULES([VAPIGEN],[vapigen]) in configure.ac inside of the if test "$enable_vala" = "yes" block)

[Eric Gregory]

Running this with Vala from Git master is resulting in a very similar error:


  GEN    WebKit-3.0.typelib
  GEN    Source/WebKit/gtk/vala/webkitgtk-3.0.vapi
/bin/bash: line 1: --library: command not found
make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/home/eric/Development/WebKit'
make: *** [all] Error 2

[Evan Nemerson]

(In reply to comment #18)
> Running this with Vala from Git master is resulting in a very similar error:
> 
> 
>   GEN    WebKit-3.0.typelib
>   GEN    Source/WebKit/gtk/vala/webkitgtk-3.0.vapi
> /bin/bash: line 1: --library: command not found
> make[1]: *** [Source/WebKit/gtk/vala/webkitgtk-3.0.vapi] Error 127
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory `/home/eric/Development/WebKit'
> make: *** [all] Error 2

Did you pass --enable-vapigen when you built vala? Are you sure you installed it to the right prefix?

From the error, it seems like the VAPIGEN variable is empty when it should point to the vapigen executable. It should be set to `pkg-config --variable=vapigen vapigen`, which requires the vapigen pkg-config file. If you're not installing to a standard location, you may need to use the PKG_CONFIG_PATH environment variable to make sure pkg-config is looking in the right location.

[Eric Gregory]

Success!  Finally got it to build.  And with your new metadata file my test program compiles and runs just fine.

Problem wasn't with pkg-config, it was with the VAPIGEN variable.  I had to set it manually, which I'm guessing was not the intention here.

One question though -- what's the deal with JavaScriptCoreGTK?  Is this not intended to be available to the outside world?  (I'm new to WebKit so forgive my newb-ish question!)

[Evan Nemerson]

Created attachment 123779 [details]
[GTK] Add Vala bindings

This version adds a pkg-config check for vapigen instead of just assuming it exists. Should fix the issue Eric is having (provided you accept "emits an error message during configure instead of a more cryptic one during build" as a valid definition of "fix").

[Evan Nemerson]

(In reply to comment #20)
> Success!  Finally got it to build.  And with your new metadata file my test program compiles and runs just fine.
> 
> Problem wasn't with pkg-config, it was with the VAPIGEN variable.  I had to set it manually, which I'm guessing was not the intention here.

You shouldn't have to set it manually. It should be set for you using the vapigen pkg-config file, which I only added to Vala a few days ago. Can you try with the patch I just posted?

If you need help getting it to work, stop by the #vala channel on gimpnet or #webkitgtk+ on freenode and ping me ("nemequ").

[Eric Gregory]

Evan, it works fine with your new patch.  Looks good to me!

[Martin Robinson]

I think this patch is just waiting on approval from the WebKitGTK+ community at large. Would someone be willing to send a proposal to the webkit-gtk list with the reasons for doing this? I don't think there will be much opposition.

[Eric Gregory]

I discovered two errors in the Vapi today -- both are methods where the return type should be nullable:

DOM.Document.get_element_by_id()
DOM.Node.get_parent_element()

There's probably a few similar functions that have the same issue.

[Evan Nemerson]

(In reply to comment #25)
> I discovered two errors in the Vapi today -- both are methods where the return type should be nullable:
> 
> DOM.Document.get_element_by_id()
> DOM.Node.get_parent_element()
> 
> There's probably a few similar functions that have the same issue.

Yes, that's likely true. See https://live.gnome.org/Vala/UpstreamGuide#Nullability_of_Return_Values

Any functions with nullable return values should be fixed using the metadata file until G-I fixes the issue upstream, at which time the annotations will have to be modified.

FWIW, the fix should be adding these two lines to the metadata file:

DOMDocument.get_element_by_id nullable
DOMNode.get_parent_element nullable

[Eric Gregory]

Not sure if this feature is still being considered or not, but I have another issue to report with the Vapi.  

It seems DOMEventTarget.add_event_listener() made it into the GIR file, but somehow doesn't appear in the Vapi.  Evan, think you could take a look at that one?  We're scratching our heads over this.

[Eric Gregory]

This is no longer needed.  Newer versions of Vala can bind to GIR directly without needed a vapi.  Some fixups ("metadata") are needed, however, but that seems like it belongs in the Vala project.

For more info please see our ticket here:
http://redmine.yorba.org/issues/6139