[Xcb] ANNOUNCE: X Haskell Bindings 0.3

[Barton C Massey]

The suggested approach, as I think you understand, is to
bind to the XCB bottom-half.  You can use the socket handoff
mechanism, which allows you to continue to generate the
protocol stream using your current code, while allowing
folks to integrate Xlib and C/XCB code into XHSB apps.

One thing really lacking in XCB right now is adequate
documentation for this interface.  We've been talking about
what to do about that.

	Bart

In message <694519c50906281112y50e5de4au452a21f607ec1192 at mail.gmail.com> you wrote:
> On Sun, Jun 28, 2009 at 12:52 PM, Antoine Latter<aslatter at gmail.com> wrote:
> > I'd like to announce the 0.3.* series release of the X Haskell
> > Bindings. =A0This release, like the prior 0.2.* series focuses on making
> > the API prettier. This release is based on the XCB protocol
> > descriptions version 1.5
> >
> 
> I'd also like to share my thoughts on where the XHB project is, and
> where I see it going.
> 
> As an experiment to show that an X client library can be written in
> Haskell, I feel like XHB has succeeded.
> 
> But to be truly useful as a library, I feel like it needs to be able
> to inter-operate with xlib and libxcb, which XHB currently does not.
> 
> Conceptually, XHB can be thought of as two parts:
> 
>  - Haskell data types generated from the X protocol description, which
> know how to serilaize/deserialize themselves to and from byte streams.
> 
>  - A runtime which knows how to open a connection to the X server, and
> knows how to peek and poke stuff onto the connection to the X server
> (this is where all of the networking and thread wrangling code lives).
> 
> So it seems to me that the path forward is to keep as much of the
> first part as possible, and then replace the second part with haskell
> bindings to XCB.
> 
> I've started the binding to libxcb here:
> http://community.haskell.org/~aslatter/code/xcb-ffi/
> 
> 
> There are still a few unknowns in my mind, such as
>  - I've never made Haskell bindings to a multi-threaded C App. Is
> there anything strange I have to worry about?
> 
>  - I have no idea how I'll map event and error codes to the function
> to decode the bytes into a Haskell type. In XHB all of the information
> needed lives in Haskell datatypes - once I start moving over to being
> a wrapper around XCB, the extensions cache is held in libxcb and isn't
> exposed publicly.
> 
> But presumably these problems have solutions.
> 
> Antoine
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb