Closed jdm closed 9 years ago
When I started this project, there didn't seem to be any xlib or glx bindings on crates.io, but I needed them for one of my other projects. I planned on putting other X11 related libraries (xcb, xft, xrandr, etc) in here as well when I get the time. It would be nice to merge them somehow with servo's X11 bindings to prevent duplication of efforts.
There's also been talk of merging glutin's X11 bindings (which are also extensive) with rust-xlib, but we would need to put rust-xlib on crates.io first. If we can just shift over to using x11-rs instead, that's even less work :)
That all sounds good to me! How would we go about making this happen?
Presumably a PR to glutin that removes ffi.rs and uses a released version of x11-rs. It would be worth ensuring that @tomaka is open to this idea, too :)
I've suggested the idea to @tomaka, and I'm currently adding everything glutin
needs to x11-rs
.
To answer your original question, generating the bindings from XML as in rust-glx
is probably better than hand writing them like I've done here. I'll see if I can switch to that method for my GLX bindings as well as adding generated XCB bindings.
There are actually some generated XCB bindings over at https://github.com/Aatch/rust-xcb, they just haven't been updated for a while. I've been working on trying to make things compile now that rust seems to be in a more stable place.
I haven't worked with glgenerator before. When used by glutin, it appears to remove prefixes (glX
for functions and `GLX` for constants) from symbols. Can it generate bindings without doing this? It would be inconsistent with the current style of x11-rs.
@bjz ^
By generating function bindings from the C headers, the Xlib and GLX bindings are much more complete now. Everything exported by libX11.so that starts with a capital X is covered. Any structs needed by those functions were added as well (except many used by Xkb and Xcms which were big enough to get their own sub-modules). Other than that, all that's really missing are many of the constants in the C headers.
I came across this while looking at how realistic it would be to merge https://github.com/servo/rust-xlib/ and x11-rs. Is there a reason to prefer this repository's glx module over https://github.com/servo/rust-glx/?