vapigen is trying to introspect X11 API which is obviously not introspectable. And X11 API will not be introspectable ever. How can you explain that to vapigen?

I could hide xkl_engine_filter_events from introspection but I would not like to do it.

Tried to add the (skip) attribute to that parameter. Could you please check from git?

I tried the skip but it seems that way does not resolve the problem.

% vapigen /usr/share/gir-1.0/Gkbd-3.0.gir --library gkbd \
  --pkg gtk+-3.0 --pkg glib-2.0 --pkg gmodule-2.0
Xkl-1.0.gir:877.54-877.54: error: The type name `X.XEvent' could not be found
            <type name="xlib.XEvent" c:type="XEvent*" skip="1"/>
                                                     ^

I don't know if Xkl-1.0.metadata can resolve this.
http://live.gnome.org/Vala/Bindings

I mean the change does not resolve this problem.

--- Xkl-1.0.gir.orig
+++ Xkl-1.0.gir
@@ -871,7 +871,7 @@
           <type name="gint" c:type="gint"/>
         </return-value>
         <parameters>
-          <parameter name="evt" transfer-ownership="none">
+          <parameter name="evt" transfer-ownership="none" skip="1">
             <doc xml:whitespace="preserve">delivered X event</doc>
             <type name="xlib.XEvent" c:type="XEvent*"/>
           </parameter>

I guess it is a bug in vapigen then - it should ignore the parameters marked as "skip", according to the introspection docs:

http://live.gnome.org/GObjectIntrospection/Annotations

(skip) used to indicate that the parameter or return value is only useful in C and should be skipped (bug)

What do you think?

OK, it seems this problem can be fixed by Xkl-1.0.metadata

# cat Xkl-1.0.metadata 
Xkl cheader_filename="libxklavier/xklavier.h"
Engine.filter_events.evt ref type="X.Event"


# vapigen /usr/share/gir-1.0/Gkbd-3.0.gir --library gkbd --metadatadir=. \
  --pkg gtk+-3.0 --pkg glib-2.0 --pkg gmodule-2.0

It might be good if libgnomekbd could provide gkbd.vapi. Currently I generate gkbd.vapi during the ibus build.

> It might be good if libgnomekbd could provide gkbd.vapi. Currently I generate
> gkbd.vapi during the ibus build.
I do not mind, if that is the standard practice for gnome libraries. What do other libraries do in relation to vapi?

(In reply to comment #8)
> > It might be good if libgnomekbd could provide gkbd.vapi. Currently I generate
> > gkbd.vapi during the ibus build.
> I do not mind, if that is the standard practice for gnome libraries. What do
> other libraries do in relation to vapi?

The vala files are maintained as source codes only. 'valac --ccode' can convert the vala files to C files.

e.g.

% cat Xkl-1.0.metadata 
Xkl cheader_filename="libxklavier/xklavier.h"
Engine.filter_events.evt ref type="X.Event"

% cat Gkbd-3.0.metadata
Configuration cheader_filename="libgnomekbd/gkbd-configuration.h"

% vapigen /usr/share/gir-1.0/Gkbd-3.0.gir --library gkbd --metadatadir=. \
  --pkg gtk+-3.0 --pkg glib-2.0 --pkg gmodule-2.0

% ls
a.vala gkbd.vapi Xkl-1.0.metadata Gkbd-3.0.metadata

% cat a.vala
using Gkbd;

private Gkbd.Configuration m_config = null;

public static int main (string[] argv) {
    m_config = Gkbd.Configuration.get();
    return 0;
}

% valac --vapidir . \
  --pkg gkbd --pkg gtk+-3.0 --pkg gmodule-2.0 --pkg Xkl-1.0 \
  --metadatadir . --ccode \
  a.vala

% ls
a.c a.vala gkbd.vapi Xkl-1.0.metadata Gkbd-3.0.metadata

Ok, feel free to submit the patch

(In reply to comment #10)
> Ok, feel free to submit the patch

The patch has ever been submitted?  If nobody minds I can file a slightly modified version (for Caribou) to vala itself, which might make more sense because libxklavier wouldn't need extra dependency to vapigen.

(In reply to comment #11)
> (In reply to comment #10)
> > Ok, feel free to submit the patch
> 
> The patch has ever been submitted?  If nobody minds I can file a slightly
> modified version (for Caribou) to vala itself, which might make more sense
> because libxklavier wouldn't need extra dependency to vapigen.

Great. I'm a bit busy to work on it.