I just pushed the first release of the Haskell bindings to Wayland I've been working on to Hackage. SHAMELESS SPAM ----- I'm looking for a PhD position in (mathematical) type theory (preferably in Europe). Contact me for my (interesting!) background. What is Wayland? ----- For those of you who have been living under a rock, X11 is probably going to be ditched soon (porting work for GNOME, KDE, and E is already well underway), and the graphics stack reworked, in favor of "wayland". There will no longer be a monolithic server between the compositor (aka window manager) and the window clients. In the new design, the compositor *is* the central server. The new architecture allows for proper isolation of clients (a HUGE security improvement over X11), as well as major cleanups of code (enabling embedded use). Why bind to C code? ----- In theory, wayland should only be a protocol specification (which happens to have a reference implementation) which could be implemented in Haskell. However, the current state of the matter is that for EGL implementation reasons, one is forced to bind to this reference implementation. (More precisely, the EGL libraries need to be able to configure wayland - and such code would have to be written for every wayland implementation.) So in practice, one can't write a pure Haskell implementation, and that's why I made bindings for the C library. Where's the code? ----- https://github.com/tulcod/haskell-wayland Wait, why are you even binding to Wayland? ----- Not sure, but it's pretty foundational stuff so I'm sure it'll be of use to someone, somewhere. Maybe someone wants to write a window manager for the new ecosystem (I'm looking at you XMonad)? Wow, I've never seen a module expose this many symbols ----- Yes, if anyone has ideas on how to reorganize and/or clean up the symbols exposed by the various part of the library, I am most interested. The problem here is that I'm generating a lot of code using template haskell, and TH does not give you control over which symbols you want to expose and how. I could write this list to a haskell source file at configure time instead (which might be useful for other reasons as well), but ideally I would like to split up the library into the various "interfaces" wayland offers - but these interfaces are unknown at dev time time, and I don't think there is remotely any mechanism to generate /modules/ at compile time. I'm interested to hear what you guys think about controlling the symbol exposure of TH-generated code. TemplateHaskell /and/ GeneralizedNewtypeDeriving? Are you /trying/ to derive bottom? ----- Well I sacrificed some Safety in favor of exposing nice Haskelly types. Feedback is welcome. Final note ----- By the way, I also wrote bindings to xkbcommon a while ago, although they need some attention. Anyway, my point is that with hayland and xkbcommon in place (both in a semi-usable state), there should be plenty of groundwork ready for you to get started with Wayland on Haskell. (xkbcommon is the de facto standard library to work with keyboard layouts in wayland. It translates keyboard events ("which key did you press") into Unicode symbols ("what letter should appear on the screen"), using the right keyboard layout.)