
I'd like to announce the 0.3.* series release of the X Haskell Bindings. This 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 This does mean that there's a good chance this is a breaking release for any code compiled against 0.2.*. The goal of XHB is to provide a Haskell implementation of the X11 wire protocol, similar in spirit to the X protocol C-language Binding (XCB). On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb Source: darcs get http://community.haskell.org/~aslatter/code/xhb/ New this release: * In 0.2, a lot of the core protocol requests, events and replies were updated to use prettier Haskell datatypes for the various enums and bitmasks. Thanks to Peter Harris's work on the protocol description XML files, these niceties have extended out to all of the extension requests, events and replies and such. * Due to name clashes, I the type-names for events and errors now include an "Event" or "Error" suffix. For example, the type "Notify" has become "NotifyEvent". * Now based on the protocol description version 1.5, from 1.4. Related projects: X protocol C-language Binding: http://xcb.freedesktop.org/

On Sun, Jun 28, 2009 at 12:52 PM, Antoine Latter
I'd like to announce the 0.3.* series release of the X Haskell Bindings. This 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

On Sun, Jun 28, 2009 at 01:12:35PM -0500, Antoine Latter wrote:
On Sun, Jun 28, 2009 at 12:52 PM, Antoine Latter
wrote: I'd like to announce the 0.3.* series release of the X Haskell Bindings. This 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.
I am not sure if you have seen this, but one of the first (perhaps the first?) haskell GUI library was a direct implementation of the X protocol. http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/ John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (2)
-
Antoine Latter
-
John Meacham