Created attachment 104786 [details]
xcb.vapi

First part - the not-autogenerated headers. Now I am going to revise my xslt to autogenerate the rest.

Created attachment 104810 [details]
xcb_to_vapi.rb

Not perfect script. See inside for details (lot's TODO's).
If anybody want's to improve it please feel welcomed.

Created attachment 104986 [details]
vala-client.xsl

This XSLT script should do it's work. However it is still missing some functions - from which most important changing names to C and Vala names.
I will finish it probably tomorrow. I probably extend by those functions libxslt (in C or in vala - however I can't find libxslt bindings - only xml)

Created attachment 105033 [details]
xcb.head.vapi

Created attachment 105034 [details]
vala-client.xsl

Created attachment 105035 [details]
xcbproc.pl

Still imperfect - c:type do not work from some reasons.

Created attachment 105060 [details] [review]
xcb.patch

Still imperfect patch (strange naming of fields, 1 as field name etc.) but it can be solved by hash in script or separate metadata file.

Created attachment 105147 [details] [review]
xcb-diff.patch

XCB:XProto support seems to be reade.

Todo:
* Add extensions. Possibly in other files
* Possibly more OOP API:
Window w;
Connection conn;
//...
GetWindowAttributesCookie cookie;
cookie = w.getAttributes (conn);

Created attachment 105150 [details] [review]
xcb-diff.patch

Addition of few XLib-integration functions

I notice such problem:
If we map Xid's to classes in XCB we get multinheritance (for example Xcb.Window is Xcb.Drawable and Xcb.GLX.Drawable). Any idea how to solve it? 

Maybe one of the two or both should be an interface? (Might need some extensions in Vala)

There is one problem (except lack of support to intefaces for non GObject) - 
parser should search the xidunions in all files. More elegant solution from xcb binding would be an autocasting union. But I imaging it is worst sin in high-level language ;)

Other solution would be implicit cast. Olthought I imagine it can complicate vala internalities.

(In reply to comment #13)
> Other solution would be implicit cast. Olthought I imagine it can complicate

s/Olthought/Althought/g; - sorry for error.
> vala internalities.
> 

I can start writing bindings if I know which constructions I am allow to use. 

List proposed as so far:
1. Interfaces
2. Unions
3. Implicit casts

Regards

Is it really an issue if users have to explicitly cast?

var glx = (Xcb.GLX.Drawable) some_other_drawable;
...

I've never really used xcb, so I don't know typical use cases, maybe code examples might help.

Possibly not. 

Something like

Possibly quick'n'dirty syntax:
Xcb.GC gc;
Xcb.create_gc(conn, gc, (Xcb.Drawable) window,
              Xcb.GCMask.FOREGROUND, {screen.black_pixel});
Xcb.flush();
Xcb.poly_point (conn, Xcb.CoordMode.ORIGIN, (Xcb.Drawable)window, gc, 1, point);

Xcb.free_gc(conn, gc);

OO syntax:

Xcb.GC gc;
Xcb.Cookie cookie = gc.create (conn, (Xcb.Drawable) window,
                               Xcb.GCMask.FOREGROUND, {screen.black_pixel});
Xcb.flush ();
gc.poly_point (conn, Xcb.CoordMode.ORIGIN, (Xcb.Drawable)window, 1, point);
// Or:
// ((Xcb.Drawable)window).poly_point (conn, Xcb.CoordMode.ORIGIN, gc, 1, point);
gc.free (conn)
(c

My preffered syntax, however not possibly in simple binding of C library (implementation of some parts in Vala seems to be required) would be:
//Lazy object
Xcb.GC gc = Xcb.GC.create(conn, (Xcb.Drawable) window,
                          Xcb.GCMask.FOREGROUND, {screen.black_pixel});
// Force usage of gc
gc.poly_point (Xcb.CoordMode.ORIGIN, (Xcb.Drawable)window, 1, point);
// Or:
// window.poly_point (conn, Xcb.CoordMode.ORIGIN, gc, 1, point);

1. Sorry it should be (in preferred syntex):
Xcb.GC gc = new Xcb.GC(conn, (Xcb.Drawable) window,
                       Xcb.GCMask.FOREGROUND, {screen.black_pixel});

2. Recently I suffer from lack of time. I hope I will have it in middle of march but more probable is that I will not have it before June.

commit bcdf1d1a3c077b19cb2c6d5d3454c6f06e79435e
Author: Jürg Billeter <j@bitron.ch>
Date:   Fri Apr 24 00:09:08 2009 +0200

    Add initial x11, xcb, and cairo-xcb bindings
    
    Fixes bug 515435.

(In reply to comment #18)
> commit bcdf1d1a3c077b19cb2c6d5d3454c6f06e79435e
> Author: Jürg Billeter <j@bitron.ch>
> Date:   Fri Apr 24 00:09:08 2009 +0200
> 
>     Add initial x11, xcb, and cairo-xcb bindings
> 
>     Fixes bug 515435.
> 

Still many things are undone I guess.

1. The bindings can be generated from xcb-proto metadata files. I guess it is the 'proper' would be proper way.

2, Even hand written would not go around the problem of multiinheritance which is required for full xcb building.