The GLFW-b package

[ Tags: bsd3, graphics, library ] [ Propose Tags ]

Bindings to GLFW, a free, open source, multi-platform library for creating OpenGL contexts and managing input, including keyboard, mouse, joystick and time.

GLFW-b does not currently work on Mac OS X. Sorry.

Please see ( for information about how these bindings differ from the ones in the GLFW package (

For more information about the library on which these bindings are based, please see

[Skip to Readme]


Versions 0.0.1, 0.0.2,,,,,,,,,,,,,,,,, 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.2.0, 1.2.1, 1.3, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7,,,,,
Dependencies base (==4.*) [details]
License BSD3
Author Brian Lewis <>
Maintainer Brian Lewis <>
Category Graphics
Source repo head: git clone git://
Uploaded Fri Jan 8 18:41:03 UTC 2010 by BrianLewis
Distributions LTSHaskell:, NixOS:, Stackage:, openSUSE:
Downloads 21866 total (357 in the last 30 days)
Rating (no votes yet) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]
Hackage Matrix CI




Maintainer's Corner

For package maintainers and hackage trustees

Readme for GLFW-b-0.0.1

[back to package description]

Differences between GLFW and GLFW-b 2010.01

  • GLFW binds to version 2.6 of the GLFW C library. GLFW-b binds to 2.7. GLFW 2.7 is partially written in Objective C. This is a problem for Cabal, so GLFW-b does not currently work on Mac OS X.

  • Some GLFW functions return OpenGL {Gettable,Settable}StateVars. I don't like this because it adds an extra step to extract a value and causes GLFW to be dependent on OpenGL. GLFW-b doesn't depend on OpenGL.

  • GLFW sometimes depends on GLFW C library internally defined values. GLFW-b doesn't. For example, GLFW-b doesn't assume that GL_FALSE = 0. I don't think this makes a difference in practice, but it makes me feel better.

  • GLFW sometimes assumes that certain Haskell types are equivalent to certain C types, e.g. Int and int. GLFW-b doesn't. GLFW-b always uses the appropriate type from Foreign.C.Types. I don't think this makes a difference in practice, but it makes me feel better.

  • GLFW contains workarounds for a bugs in GHC < 6.10 FFI. GLFW-b doesn't.

  • GLFW's API is pretty faithful to the C API. GLFW-b prefers to use full words and self-explanatory function names.

  • In GLFW-b, registering hints and opening a window are combined into one step.

  • GLFW has support for loading textures and rendering strings. GLFW-b doesn't.